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Government  and  industry  have  the  need  to  improve  the  maturity  of  their  internal 
acquisition  processes.  In  order  for  organizations  to  make  improvements,  they  must  know 
the  ultimate  goal  and  what  is  required  to  achieve  that  goal.  Additionally,  progress  toward 
achieving  the  goal  must  be  measurable.  A  capability  maturity  model®  provides  the 
framework  needed  to  facilitate  the  desired  improvement.  The  Software  Acquisition 
Capability  Maturity  Model  (SA-CMM®)  has  been  developed  to  provide  such  a 
framework. 

Version  1.02  incorporated  change  requests  that  were  received,  as  well  as  the  results  of 
lessons  learned  from  conducting  appraisals  and  from  the  use  of  Version  1.01. 

This  new  version  incorporates  the  additional  change  requests  that  have  been  received  to 
date.  Also,  several  changes  were  made  to  incorporate  concepts  from  the  Capability 
Maturity  Model  Integration  (CMMI^*^)  project. 

Constructive  comments,  using  the  form  at  the  end  of  this  document,  resulting  from  the 
use  of  Version  1.03  of  the  SA-CMM  are  not  only  welcome  but  are  encouraged. 

The  Context  of  the  SA-CMM 

The  experience  of  the  Software  Engineering  Institute  in  developing  the  Capability 
Maturity  Model  for  Software  (SW-CMM)  was  directly  applicable  to  developing  the  SA- 
CMM.  The  SW-CMM  describes  the  developer’s  (supplier’s)  role  while  the  SA-CMM 
describes  the  buyer’s  (acquirer’s)  role  in  the  acquisition  process.  In  the  SA-CMM  an 
individual  acquisition  begins  with  the  process  of  defining  a  system  need.  Some  activities 
performed  by  the  acquisition  organization,  such  as  planning,  may  pre-date  the 
establishment  of  a  project  office.  The  SA-CMM  includes  certain  pre-contract  award 
activities,  such  as  preparing  the  solicitation  package,  developing  the  initial  set  of 
requirements,  and  participating  in  source  selection.  In  the  SA-CMM  an  individual 
acquisition  ends  when  the  contract  for  the  products  is  concluded. 

The  SA-CMM  identifies  key  process  areas  for  four  of  its  five  levels  of  maturity.  The  key 
process  areas  state  the  goals  that  must  be  satisfied  to  achieve  each  level  of  maturity.  In 
other  words,  progress  is  made  in  stages  or  steps.  The  levels  of  maturity  and  their  key 
process  areas  thus  provide  a  roadmap  for  achieving  higher  levels  of  maturity. 

Typically,  a  portion  of  the  goals  or  activities  of  some  higher-level  key  process  areas  are 
satisfied/performed  at  a  lower  level.  However,  a  key  process  area  cannot  be  achieved 
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until  all  of  its  goals  have  been  satisfied.  A  maturity  level  is  achieved  by  mastering  all  of 
the  key  process  areas  at  that  level.  Once  a  maturity  level  is  achieved,  the  concept  of  the 
model  requires  that  the  satisfaction  of  all  lower  level  goals  be  maintained. 

The  stages  of  the  model  are  complementary  and  flow  upward.  For  example,  at  Level  2 
some  of  the  activities  of  Contract  Tracking  and  Oversight  will  result  in  corrective  actions 
(a  reactive  approach  to  deficiencies).  This  process  grows  and  matures;  in  Level  3  the 
activities  of  Contract  Performance  Management  are  performed  to  identify  and  prepare  for 
deficiencies  before  they  occur  (a  proactive  approach).  Contract  Performance 
Management  grows  and  matures  to  become  Quantitative  Acquisition  Management  at 
Level  4  when  the  process(es)  is  adjusted  based  on  quantitative  data  (quantitative 
approach).  At  Level  5,  Continuous  Process  Improvement  uses  quantitative  data  to 
optimize  process  performance  (optimizing  approach). 

In  the  SA-CMM  activities  or  events  that  occur  at  a  lower  level  are  not  required  to  be  re¬ 
instantiated  at  higher  levels.  For  example,  a  group  is  established  for  managing  the 
contract  in  the  Contract  Tracking  and  Oversight  key  process  area  at  Level  2,  the  SA- 
CMM  assumes  that  the  same  group  remains  in  place  when  the  organization  moves  to 
Level  3.  Thus,  there  is  no  requirement  in  the  Contract  Performance  Management  key 
process  area  at  Level  3  to  re-establish  a  contract  management  group.  This  approach 
reduces  unnecessary  redundancy  in  subsequent  key  process  areas  and  makes 
implementation  more  efficient. 

The  SA-CMM  is  designed  to  be  sufficiently  generic  for  use  by  any  government  or 
industry  organization,  regardless  of  size,  acquiring  products.  When  applying  the  SA- 
CMM  to  a  particular  organization,  translations  may  need  to  be  made.  The  acquisition 
organization  specializes  in  acquisition  and  may  be  responsible  for  more  than  one  project. 
The  project  team  is  the  entity  that  has  the  responsibility  for  executing  the  specific 
acquisition.  The  project  team  is  supported  by  “other  (affected)  groups”  (functionals, 
matrix,  etc.)  in  the  conduct  of  the  acquisition.  In  the  SA-CMM,  the  terms  “group,” 
“team,”  “office,”  and  similar  terms  may  indicate  situations  where  the  specific 
implementation  may  vary  from  a  single  individual  assigned  part-time,  to  several  part-time 
individuals  assigned  from  other  organizations,  to  several  individuals  dedicated  full-time. 
The  organizational  structure  of  the  model  must  be  mapped  onto  the  particular 
organization  where  the  model  is  being  applied.  Also,  the  terminology  of  the  model  has 
been  made  as  generic  as  possible  and  must  be  mapped  onto  the  local  situation;  some 
examples  are  “contracting  official,”  “affected  groups,”  and  “domain.” 

The  SA-CMM  should  be  interpreted  in  the  context  of  the  needs  of  the  organization;  just 
because  something  is  in  the  SA-CMM  does  not  mean  it  should  be  applied  automatically. 
Effective  and  efficient  acquisition  processes  are  critical  to  successful  process 
improvement,  but  the  quality  of  their  output  can  only  be  determined  in  the  context  of  the 
business  needs  of  the  organization. 
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Use  of  the  SA-CMM  is  not  limited  to  situations  where  the  products  are  being  acquired 
under  formal  contract.  It  can  be  used  by  any  organization  acquiring  products.  For  this 
usage,  the  term  “supplier”  refers  to  the  organization  performing  the  required  effort.  The 
term  “project  team”  refers  to  the  individuals  within  the  acquiring  organization  who  have 
an  assigned  acquisition  responsibility,  and  the  term  “contract”  refers  to  the  agreement 
between  the  organizations. 

The  SA-CMM  applies  to  the  acquisition  of  all  types  of  embedded  and  stand-alone 
software  applications,  including  those  where  commercial-off-the-shelf  (COTS)  and  non- 
developmental  item  (NDI)  software  are  being  acquired,  either  as  a  part  of  a  system  or 
separately.  Naturally,  the  model  may  have  to  be  interpreted  to  fit  the  specific 
circumstances. 

The  SA-CMM  is  appropriate  for  use  throughout  the  entire  system  life  cycle.  During  the 
life  cycle  of  a  system,  many  individual  acquisitions  can  occur;  an  acquisition  can  occur  in 
the  system’s  operational  and  support  phase  as  well  as  during  its  initial  development 
phase.  In  cases  where  products  for  enhancing  or  reengineering  an  item  are  being 
acquired,  the  support  organization  takes  on  the  role  of  the  acquirer.  Thus,  the  model  is 
repeatedly  applicable  during  the  life  cycle  of  a  system. 

Every  acquisition  project  germinates  with  a  requirement,  albeit  at  a  very  high  level.  As 
the  acquisition  begins  to  form,  more  requirements  are  identified  and  refined.  This 
evolution  proceeds  and  the  set  of  requirements  continues  to  grow.  By  the  time  the 
solicitation  package  is  developed,  a  significant  set  of  technical  and  non-technical 
requirements  exists.  For  purposes  of  the  SA-CMM,  these  requirements  must  be  baselined 
(managed  and  controlled),  not  frozen.  As  requirements  further  evolve  (e.g.,  allocation, 
elaboration,  and  refinement),  they  are  incorporated  into  the  requirements  baseline,  and 
managed  and  controlled.  Management  and  control  of  the  requirements  remain  the 
acquirer’s  responsibility  even  though  the  supplier  team  may  be  involved  in  the 
requirements  development  process. 

A  project  should  have  established  baselines  for  the  product’s  technical  and  non-technical 
requirements,  for  the  cost  of  the  products  being  acquired,  and  for  the  schedule  of  the 
acquisition  project. 

The  SA-CMM  is  based  on  the  expectation  that  a  mature  organization  and  its  projects  will 
do  a  thorough  job  of  planning  an  acquisition.  The  Software  Acquisition  Planning  key 
process  area  addresses  the  planning  process  that  must  take  place  as  an  adjunct  to 
managing  the  acquisition  project.  Each  of  the  remaining  key  process  areas  addresses  a 
planning  process  as  one  of  the  area’s  activities.  How  to  document  this  planning  is  the 
option  of  the  acquisition  organization  and  the  project  team.  While  other  planning 
documents  may  be  created  for  the  project,  the  SA-CMM  does  identify  two  specific 
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plans — the  Project  Management  Plan  and  the  Acquisition  Risk  Management  Plan.  The 
method  of  documenting  these  two  specific  plans  is  also  the  option  of  the  acquisition 
organization  and  the  project  team.  The  resulting  project  planning  documentation  need 
not  be  any  more  extensive  than  that  of  any  well-managed  acquisition  project. 

The  Architecture  of  the  SA-CMM 


Figure  1.  SA-CMM  Architecture 

The  SA-CMM  defines  five  levels  of  maturity.  Each  maturity  level  (except  Level  1) 
indicates  process  capability  and  contains  key  process  areas.  Figure  1  depicts  the 
architecture  of  the  SA-CMM  and  Figure  2  provides  a  synopsis  of  its  content.  The 
components  of  the  architecture  are  described  below: 

Goals.  Goals  are  the  aggregate  result  achieved  by  the  effective  implementation  of  the  key 
process  area. 

Commitment  to  perform.  Commitment  to  perform  describes  the  actions  that  the 
organization  must  take  to  establish  the  process  and  ensure  that  it  can  endure. 

Commitment  to  perform  typically  involves  establishing  organizational  policies  and 
management  sponsorship. 

Ability  to  perform.  Ability  to  perform  describes  the  preconditions  that  must  exist  in  the 
project  or  organization  to  implement  the  acquisition  process  competently.  Ability  to 
perform  typically  involves  resources,  organizational  structures,  and  training. 
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Activities  performed.  Activities  performed  describes  the  roles  and  procedures  necessary 
to  implement  a  key  process  area.  Activities  performed  typically  involves  establishing 
plans  and  procedures,  performing  the  work,  tracking  it,  and  taking  appropriate 
management  actions. 

Measurement  and  analysis.  Measurement  and  analysis  describes  the  need  to  measure 
the  process  performance  and  analyze  these  measurements.  Measurement  and  analysis 
typically  includes  examples  of  the  measurements  that  could  be  taken  to  determine  the 
status  of  the  activities  performed. 

Verifying  implementation.  Verifying  implementation  describes  the  steps  to  ensure  that 
the  activities  are  performed  in  compliance  with  the  process  that  has  been  established. 
Verifying  implementation  typically  encompasses  reviews  by  management. 

The  Maturity  Levels  of  the  SA-CMM 

The  acquisition  organization  management  must  increase  its  involvement,  leadership,  and 
discipline  as  it  attempts  to  achieve  each  higher  level  of  maturity.  The  maturity  levels 
provide  a  roadmap  for  the  continuous  improvement  of  an  organization’s  acquisition 
process;  they  are  not  intended  to  serve  as  a  rating  mechanism.  The  following  describes 
the  five  maturity  levels  of  the  SA-CMM,  highlighting  the  primary  process  improvements 
made  at  each  level. 

1)  Initial  -  The  acquisition  process  is  characterized  as  ad  hoc,  and  occasionally  even 
chaotic.  Few  processes  are  defined  and  success  depends  on  individual  effort.  For  an 
organization  to  mature  beyond  the  initial  level,  it  must  install  basic  management  controls 
to  instill  self-discipline. 

2)  Repeatable  -  Basic  acquisition  project  management  processes  are  established  to  plan 
all  aspects  of  the  acquisition,  manage  requirements,  track  project  team  and  supplier  team 
performance,  manage  the  project’s  cost  and  schedule  baselines,  evaluate  the  products,  and 
successfully  transition  a  product  to  its  support  organization.  The  project  team  is  basically 
reacting  to  circumstances  of  the  acquisition  as  they  arise.  The  necessary  process 
discipline  is  in  place  to  repeat  earlier  successes  on  projects  in  similar  domains.  For  an 
organization  to  mature  beyond  the  level  of  self-discipline,  it  must  use  well-defined 
processes  as  a  foundation  for  improvement. 

3)  Defined  -  The  acquisition  organization’s  acquisition  process  is  documented  and 
standardized.  All  projects  use  an  approved,  adapted  version  of  the  organization’s 
standard  acquisition  process  for  acquiring  their  products.  Project  and  contract 
management  activities  are  proactive,  attempting  to  anticipate  and  deal  with  acquisition 
circumstances  before  they  arise.  Risk  management  is  integrated  into  all  aspects  of  the 
project,  and  the  organization  provides  the  training  required  by  personnel  involved  in  the 
acquisition.  For  an  organization  to  mature  beyond  the  level  of  defined  processes,  it  must 
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base  decisions  on  quantitative  measures  of  its  processes  and  products  so  that  objectivity 
can  be  attained  and  rational  decisions  made. 


Level 

Focus 

Key  Process  Areas 

5 

Optimizing 

Continuous  pro¬ 
cess  improvement 

Acquisition  Innovation  Management 
Continuous  Process  Improvement 

4 

Quantitative 

Quantitative 

management 

Quantitative  Acquisition  Management 
Quantitative  Process  Management 

3 

DeHned 

Process 

standardization 

Training  Program  Management 

Acquisition  Risk  Management 

Contract  Performance  Management 

Project  Performance  Management 

User  Requirements 

Process  DeHnition  and  Maintenance 

2 

Repeatable 

Basic  project 
management 

Transition  to  Support 

Evaluation 

Contract  Tracking  and  Oversight 

Project  Management 

Requirements  Development  and 

Management 

Solicitation 

Software  Acquisition  Planning 

1 

Initial 

Competent  people  and  heroics 

Figure  2.  Synopsis  of  the  SA-CMM 


4)  Quantitative  -  Detailed  measures  of  the  acquisition  processes,  products  are  collected. 
The  processes  and  products  are  quantitatively  and  qualitatively  understood  and 
controlled. 

5)  Optimizing  -  Continuous  process  improvement  is  empowered  by  quantitative  feedback 
from  the  process  and  from  piloting  innovative  ideas  and  technologies.  Ultimately  an 
organization  recognizes  that  continual  improvement  (and  continual  change)  is  necessary 
to  survive. 

Principles  Governing  the  Interpretation  of  the  SA-CMM 

Generic  Model.  The  SA-CMM  is  a  generic  model  for  broad  usage.  In  a  specific  context, 
implementation  and  improvement  needs  may  vary. 

Organizational  Improvement.  The  SA-CMM  is  a  model  for  organizational  improvement. 
The  SA-CMM  focuses  on  building  the  process  capability  of  an  organization. 
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Improvement  Roadmap.  The  activities  of  the  SA-CMM  describe  the  characteristics  of  an 
acquisition  process  that  one  would  normally  expect  to  see  at  each  maturity  level.  The  SA- 
CMM  does  not  prescribe  how  an  organization  is  to  improve  its  processes;  it  describes  the 
attributes  of  an  organization’s  process  maturity  at  five  levels  of  maturity.  The  maturity 
levels  prescribe  an  ordering  of  how  to  prioritize  process  improvement  aetions. 

Key  Process  Areas.  The  SA-CMM  describes  key  process  areas  and  activities;  it  is  not 
exhaustive,  and  additional  process  areas  may  be  appropriate  for  an  organization. 

Comprehensiveness.  The  SA-CMM  does  not  address  all  the  factors  that  impact 
acquisition.  Examples  of  excluded  topics  are  manufacturing  and  human  resources. 

Process  Management.  The  quality  of  a  product  is  largely  governed  by  the  quality  of  the 
processes  used  to  acquire,  develop,  or  maintain  it. 

No  One  Right  Way.  There  is  not  “one  right  way”  to  implement  an  acquisition  process. 
The  SA-CMM  is  not  engraved  in  stone.  Also,  except  in  a  few  carefully  chosen  instances, 
the  SA-CMM  does  not  mandate  how  the  acquisition  process  should  be  implemented  or 
who  should  perform  an  action;  it  describes  what  characteristics  the  acquisition  process 
should  possess. 

Technology.  The  SA-CMM  is  technology  independent.  No  specific  tools,  methods,  or 
technologies  are  mandated  by  the  SA-CMM.  Appropriate  tools,  methods,  and 
technologies  should  be  made  available  to  support  the  process. 

Professional  Judgement.  Professional  judgement  must  be  applied  when  interpreting,  for 
a  particular  organization,  the  activities  of  the  SA-CMM.  The  SA-CMM  should  be 
adapted  to  fit  the  organization;  the  organization  should  not  be  restructured  to  reflect  the 
SA-CMM. 


The  Competence  Principle.  The  competence  of  the  people  doing  the  work  is  a  major 
factor  in  project  performance  and  organizational  success.  (Competence  includes 
knowledge  of  the  application  domain,  acquisition  methods,  and  quantitative  methods,  and 
having  interpersonal  and  problem  solving  skills.) 
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Level  1  -  The  Initial  Level 


At  the  Initial  Level,  the  project  team  typically  does  not  provide  a  stable  environment  for 
acquiring  products.  The  project  team  is  staffed  based  on  the  availability  of  individuals,  resulting 
in  a  random  composition  of  acquisition  skills.  Acquisition  does  not  receive  adequate 
management  visibility.  The  project  is  pursued  in  an  ad  hoc  manner. 

There  are  no  key  process  areas  at  Level  1. 
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Level  2  -  The  Repeatable  Level 


At  the  Repeatable  Level,  the  project  team  is  knowledgeable  and  supportive  of  promulgated 
policies,  regulations,  and  standards  that  relate  to  its  project  and  makes  a  dedicated  attempt  to 
comply  with  them.  The  project  team  establishes  documented  acquisition  management  plans  and 
procedures.  The  planning  and  tracking  of  new  projects  are  based  on  experience  with  similar 
projects.  An  objective  in  achieving  Level  2  is  to  stabilize  both  the  contract  management  and 
project  management  processes,  allowing  project  teams  to  repeat  successful  practices  employed 
on  earlier  projects. 

Level  2  project  teams  have  instituted  basic  acquisition  management  practices  and  controls.  All 
members  of  the  team  are  committed  to  complying  with  project  plans,  required  policies, 
regulations,  and  standards.  Project  managers  track  costs,  schedules,  requirements,  and 
performance  of  the  project.  Problems  in  meeting  commitments  are  identified  when  they  arise. 
Requirements  are  baselined  and  the  content  is  controlled.  Documentation  is  evaluated  for 
compliance  with  specified  requirements.  Project  teams  work  with  their  suppliers,  and  any 
subsuppliers,  to  establish  a  stable,  cooperative  working  environment.  Project  teams  track  the 
performance  of  the  supplier  team  for  adherence  with  project  plans  and  for  ensuring  that 
contractual  requirements  are  being  satisfied. 

The  process  capability  of  Level  2  acquisition  organizations  can  be  summarized  as  being  stable 
for  planning  and  tracking  the  acquisition  because  documented  procedures  provide  a  project 
environment  for  repeating  earlier  successes. 

Level  2  key  process  areas  are: 

Software  Acquisition  Planning 
Solicitation 

Requirements  Development  and  Management 

Project  Management 

Contract  Tracking  and  Oversight 

Evaluation 

Transition  to  Support 
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Level  2:  The  Repeatable  Level 


Software  Acquisition  Planning 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for  the 
acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 

Software  Acquisition  Planning  involves  the  preparation  for  all  areas  in  acquisition  planning  such 
as  early  budgetary  action,  schedule  determination,  acquisition  strategy,  risk  identification,  and 
requirements  definition.  There  are  other  traditional  acquisition  planning  activities  that  must  be 
performed  in  the  context  of  the  system  as  a  whole  and  in  coordination  with  the  project  team  (e.g., 
system  requirements  development,  hardware/software  partitioning,  system  level  software 
requirements  allocation,  and  solicitation  management).  Software  Acquisition  Planning  also 
involves  planning  for  software  in  all  aspects  of  the  acquisition  project.  Acquisition  planning 
documentation  provides  for  implementation  of  all  acquisition-related  policies. 

Acquisition  planning  begins  with  the  earliest  identification  of  a  requirement  that  could  only  be 
satisfied  through  an  acquisition.  The  process  starts  when  reasonable  resources  are  assigned  to 
form  a  project  team  for  the  acquisition,  independent  of  whether  or  not  the  team  is  formally 
constituted  as  an  organizational  entity.  Software  acquisition  planning  provides  for  conducting 
and  documenting  acquisition  planning  activities  and  participation  in  system  level  planning 
activities  as  appropriate. 

Goals 


Goal  1  Software  acquisition  planning  documents  are  prepared  during 

acquisition  planning  and  maintained  throughout  the  acquisition. 

Goal  2  Software  acquisition  planning  addresses  the  project’s  entire  acquisition 

process  and  life  cycle  support  of  the  products  being  acquired. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  planning  the 
acquisition. 

This  policy  typically  specifies  that: 

1.  The  implementation  of  all  acquisition-related  policies  is  provided  for  in  the  plans. 

2.  The  plans  address  all  areas  of  the  acquisition. 
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Software  Acquisition  Planning 


Some  examples  of  the  areas  include: 

software  acquisition  planning, 
project  management, 
solicitation, 

requirements  development  and  management, 
contract  management, 
evaluation,  and 

j  acquisition  risk  management. _ 


3.  A  review  process  is  established  for  resolving  issues,  facilitating  acquisition  decisions,  and 
focusing  on  critical  issues  such  as  affordability  and  risk. 

4.  Responsibility  and  accountability  are  clearly  established  for  the  project. 

5.  Acquisition  planning  documentation  is  prepared  prior  to  solicitation  activities. 

6.  Acquisition  planning  documentation  is  maintained  current. 

7.  Acquisition  strategy  is  included  in  the  plans. 

Commitment  2  Responsibility  for  software  acquisition  planning  activities  is  designated. 

Ability  to  perform 


Ability  1  A  group  that  performs  the  planning  activities  of  the  acquisition  exists. 

Ability  2  Adequate  resources  are  provided  for  software  acquisition  planning 

activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 


Ability  3  The  acquisition  organization  provides  experienced  acquisition 

management  personnel  to  support  project  acquisition  planning. 


Experience  means,  for  example,  having  participated  in  acquisition  management 
planning  on  at  least  one  project,  having  a  minimum  of  five  years  acquisition 
experience,  having  knowledge  of  the  application  domain,  and  having  knowledge  of 
current  engineering  processes  and  technology. _ 
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Activities  performed 


Activity  1  Software  acquisition  planning  personnel  are  involved  in  system 

acquisition  planning. 


Activity  2 


Activity  3 


Activity  4 


Activity  5 


The  project’s  software  acquisition  planning  is  accomplished  in 
conjunction  with  system  acquisition  planning. 

The  acquisition  strategy  for  the  project  is  developed  and  documented. 

The  strategy  typically  includes  considerations  of: 

1 .  The  objectives  of  the  acquisition. 

2.  Project  constraints,  such  as  funding  and  schedules. 

3.  Available  and  projected  assets  and  technologies,  such  as  reuse,  NDI,  and  COTS. 

4.  Acquisition  methods. 

5.  Potential  contract  types  and  terms. 

6.  End  user  considerations. 

7.  Consistency  with  the  system  acquisition  strategy, 

8.  Risk  identification. 

9.  Life  cycle  support  installation  approach. 

Acquisition  planning  addresses  the  elements  of  the  acquisition  process. 


Some  examples  of  the  areas  include: 

risk  identification  and  tracking, 
project  management, 
solicitation, 

cost  and  schedule  estimates 
requirements  development  and  management, 
contract  tracking  and  oversight, 
evaluation,  and 

transition  to  support. _ 


The  project’s  acquisition  planning  is  documented  and  the  planning 
documentation  is  maintained  over  the  life  of  the  project. 
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Software  Acquisition  Planning 


Activity  6 


Activity  7 


Planning  documentation  may  be  in  a  single  document  or  in  separate  documents 
depending  on  the  specific  needs  of  the  project. _ 


Acquisition  planning  documentation  typically  includes: 

1.  All  relevant  policies  for  the  areas  of  the  acquisition. 

2.  The  tasks  to  be  performed. 

3.  The  required  acquisition  resources. 

►  Resources  include  funding,  staff,  equipment,  and  tools. 

4.  The  roles  and  responsibilities  of  the  groups  involved  in  the  project. 

Typically  roles  and  responsibilities  include: 

end  user  representation  and  involvement  in  the  acquisition, 
interface  with  system-level  activities,  and 

project  team’s  relationship  with  and  responsibilities  to  the  acquisition  organization. _ 

5.  The  project’s  strategic  objectives. 

6.  A  master  schedule  of  acquisition  milestones. 

7.  Measurements  to  determine  the  progress  of  the  acquisition. 

Life  cycle  support  of  the  software  is  included  in  software  acquisition 
planning  documentation. 

Life  cycle  support  provisions  typically  include: 

1.  Identifying  adequate  facilities  and  resources  for  the  software  support  organization. 

2.  Providing  for  transitioning  the  software  from  acquisition  to  operation  and  to  the  software 
support  organization. 

3.  Providing  for  long-term  growth  and  supportability  of  the  system. 

Life  cycle  cost  and  schedule  estimates  for  the  software  product  being 
acquired  are  prepared  and  independently  reviewed. 


In  this  instance,  “independently  reviewed”  means  a  review  by  an  individual(s)  external 
to  the  project  team. _ 
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Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  software 
acquisition  planning  activities  and  resultant  products. 

Some  examples  of  measurements  include: 
effort  expended; 
funds  expended; 

progress  towards  completion  of  acquisition  planning; 
the  acquisition  strategy,  and  life  cycle  cost  estimates;  and 
completion  of  milestones. 


Verifying  implementation 


Verification  1  Software  acquisition  planning  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  planning  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 

Verification  2  Software  acquisition  planning  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Solicitation 


Solicitation _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of  a 
particular  acquisition  and  to  select  a  supplier  who  is  best  capable  of  satisfying  the  requirements 
of  the  contract. 

Solicitation  involves  planning  and  performing  the  activities  necessary  to  issue  the  solicitation 
package,  preparing  for  the  evaluation  of  responses,  conducting  the  evaluation  of  responses, 
conducting  supporting  negotiations,  and  making  recommendations  for  award  of  the  contract. 
Solicitation  ends  with  contract  award. 

Goals 


Goal  1  The  solicitation  package  includes  the  contractual  requirements  and 

proposal  evaluation  criteria. 

Goal  2  The  technical  and  management  elements  of  proposals  are  evaluated  to 

ensure  that  the  requirements  of  the  contract  will  be  satisfied. 

Goal  3  The  selection  official  selects  a  supplier  who  is  qualified  to  satisfy  the 

contract’s  requirements  for  the  project’s  products. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  conduct  of  the 
solicitation. 

This  policy  typically  specifies  that: 

1.  Planning  for  solicitations  is  documented. 

2.  Planning  for  proposal  evaluation  activities  is  documented. 

3.  Solicitations  are  conducted  in  a  manner  compliant  with  applicable  laws,  regulations, 
policies,  and  guidance  for  the  solicitation. 

4  Solicitation  activities  are  commensurate  with  the  cost  and/or  complexity  of  the  item  or 
service  being  acquired. 
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Commitment  2 
Commitment  3 

Commitment  4 

Ability  1 
Ability  2 

Ability  3 


Ability  4 


5.  The  contract  type  (e.g.,  fixed-price,  co.st-reimbursement)  is  chosen  based  on  the  perceived 
risk  of  successfully  delivering  the  required  items  or  services  while  satisfying  the  cost  and 
schedule  requirements  of  the  contract. 

Normally,  the  less  the  risk  to  the  offeror,  the  more  rigid  the  contract  type.  For  example,  a  fixed-price 
contract  type  would  be  suitable  for  a  commodity  buy  while  a  cost-reimbursement  contract  type  is  more 
suitable  for  a  research  and  development  contract. _ 

6.  A  selection  official  is  designated  for  each  solicitation. 

Generally,  selection  officials  are  chosen  based  on  their  authority  to  commit  the  organization  to  a 
specified  dollar  amount  that  is  equal  to  or  greater  than  the  estimated  value  of  the  solicitation. _ 

7.  The  selection  official  for  a  solicitation  has  the  ultimate  responsibility  for  the  conduct  of 
the  solicitation  and  for  selecting  the  winning  offeror. 

Responsibility  for  the  solicitation  is  designated. 

A  selection  ofOcial  has  been  designated  to  be  responsible  for  the  selection 
process  and  decision. 

The  project  team  includes  contracting  specialists  for  supporting  the 
administration  of  the  contract. 

Ability  to  perform 


A  group  that  performs  and  coordinates  the  solicitation  activities  exists. 
Adequate  resources  are  provided  for  solicitation  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  solicitation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project,  having  knowledge  in  the  domain  of  the  application  being 
acquired,  and  having  familiarity  of  current  engineering  processes,  products, 
technology,  and  costing  methodologies  and  tools.  Additionally,  some  individuals 
must  have  experience  in  conducting  solicitation  activities. _ 


The  groups  supporting  the  solicitation  (e.g.,  end  user,  systems 
engineering,  support  organization,  and  application  domain  experts) 
receive  orientation  on  the  solicitation’s  objectives  and  procedures. 
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Solicitation 


Activity  1 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  solicitation  plans  and  procedures. 

The  plans  typically  cover: 

1 .  The  objectives  of  the  solicitation. 

2.  Identification  of  the  contents  of  the  solicitation  package  such  as: 

►  The  technical,  non- technical,  and  product  evaluation  requirements. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

Refer  to  the  Evaluation  key  process  area. 

►  The  proposal  evaluation  criteria. 

In  some  solicitations  a  determination  of  the  offeror’s  ability  to  perform  the  proposed  tasks,  over  and 
above  the  evaluation  of  the  material  submitted,  is  appropriate.  The  value  of  the  procurement,  the 
cost  of  the  determination,  the  staff  resources  available  to  perform  the  determination,  and  the  risk  are 
some  of  the  items  that  should  be  taken  into  account  in  determining  the  appropriateness  of  a 
determination  effort. _ _ 

►  The  statement  of  work,  including  tasks. 


Some  examples  of  contractual  tasks  include: 

engineering, 

evaluation, 

support, 

documentation,  and 
life  cycle  planning. 


►  The  contract  documentation  and  information  recording  requirements. 

Some  examples  of  contract  documentation  requirements  include: 

specifications; 

test  plans,  procedures,  reports; 
study  reports; 

configuration  management  plans,  procedures,  and  reports; 
administrative,  financial,  and  management  reports;  and 
project-specific  products  and  reports. _ 

►  The  contract  form  (e.g.,  completion  or  term),  contract  type  (e.g.,  fixed-price, 
cost-reimbursement),  incentives,  and  a  list  of  deliverable  supplies. 

►  Information  on  contract  acceptance  procedures,  specific  acceptance  criteria,  and 
payment. 

►  Additional  information  guiding  supplier  performance  during  the  contract,  including 
enabling  third-party  participation,  warranty  provisions,  and  required  data  rights. 
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►  Guidance  on  how  the  offerors  are  to  respond,  how  the  responses  will  be  evaluated, 
and  any  additional  administrative  requirements  such  as  socioeconomic  program 
compliance. 

►  Documentation  requirements  for  the  offerors  to  submit  with  their  response. 


Some  examples  of  required  submissions  include: 

an  engineering  plan  describing  how  offerors  will  carry  out  the  tasks  in  the  solicitation  package; 

a  risk  management  plan  describing  how  they  will  identify  and  manager  risks 

associated  with  the  risks  called  out  in  the  solicitation  package; 

identification  of  the  measurements  to  be  used  in  the  project  and  made  available  to 

the  project  office; 

a  statement  of  the  offeror’s  planned  use  of  NDI  and  COTS,  and  non-deliverable 
software,  including  any  limitation  on  data  rights; 
visibility  for  engineering  task  progress  and  costs  at  a  level  appropriate  for 
the  type  of  contract  and  commensurate  with  the  degree  of  risk  related  to  the 
acquisition;  and 

the  work  to  be  performed  by  subsuppliers;  and 
providing  support  for  evaluation  and  acceptance. 


Activity  2 


3.  The  participants,  responsibilities,  processes,  methodologies,  techniques,  and  schedules 
that  will  be  followed  in  the  conduct  of  the  solicitation. 

4.  The  proposal  evaluation  plans  typically  contain: 

►  A  description  of  the  proposal  evaluation  organization  structure,  including  the 
participants  and  their  responsibilities. 

►  Proposed  pre-evaluation  activities. 

►  A  summary  of  the  acquisition  strategy. 

►  A  statement  of  the  proposal  evaluation  factors  and  their  relative  importance. 

The  proposal  evaluation  factors  should  contain  factors  central  to  the  success  of  the  items  being 
acquired. _ 

►  A  description  of  the  proposal  evaluation  process,  methodology,  and  techniques  to  be 
used. 

Offerors  are  evaluated  based  on  their  past  performance,  including  domain  experience,  development 
process  maturity,  and  mature  products  in  the  relevant  domain. _ 

►  A  schedule  of  significant  proposal  evaluation  milestones. 

►  A  requirement  to  conduct  analyses  of  the  risks  associated  with  each  proposal. 

5.  A  process  for  managing  and  controlling  the  solicitation  documents. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  technical,  non-technical,  product,  and  proposal  evaluation 
requirements  are  incorporated  into  the  solicitation  package  and  resulting 
contract. 
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Solicitation 


Activity  3 
Activity  4 

Activity  5 
Activity  6 

Activity  7 


The  contract  provisions  typically  include: 

1.  Technical,  non- technical,  and  product  evaluation  requirements  to  be  satisfied  by  the 
supplier. 

2.  Criteria  that  will  be  used  to  evaluate  the  proposals. 

3.  Requirements  for  the  supplier  to  document  a  plan  for  developing  the  product. 

4.  Requirements  for  the  supplier  to  document  a  plan  for  evaluating  the  product. 

5.  Measurements  that  provide  the  project  team  visibility  into  the  supplier  team’s  process  and 
results. 

6.  Mechanisms  and  deliverables  that  provide  the  project  team  sufficient  data  to  allow 
evaluation  and  analyses  of  acquired  product. 

7.  Requirements  for  the  supplier  to  establish  a  corrective  action  system  that  includes  a 
change  control  process  for  rework  and  reevaluation. 

8.  Requirements  to  ensure  the  supplier  team  supports  each  of  the  project’s  evaluation 
activities. 

Cost  and  schedule  estimates  for  the  product  being  sought  are  prepared. 

Cost  and  schedule  estimates  are  independently  reviewed  for 
comprehensiveness  and  realism. 

In  this  instance,  “independently  reviewed”  means  a  review  by  an  individual(s)  external  to  the 

project  team. _ _ 


Proposals  are  evaluated  in  accordance  with  documented  solicitation 
plans. 

The  selection  official  uses  proposal  evaluation  results  to  support  his  or 
her  selection  decision. 


With  task  order  contracts,  the  proposal  evaluation  results  may  be  used  by  the  selection  official 
to  decide  on  awarding  of  the  task  order  or  take  other  action  as  appropriate. _ _ 


The  project  team  takes  action  to  ensure  the  mutual  understanding  of 
contract  requirements  with  the  selected  offeror(s)  immediately  prior  to 
contract  signing. 
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Measurement  and  analysis 

Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 
solicitation  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  solicitation  planning,  the 
statement  of  work,  contract  specifications,  evaluation  plans,  and 
cost  estimates;  and 

completion  of  milestones. _ 

Verifying  implementation 

Verification  1  Solicitation  activities  are  reviewed  by  the  acquisition  organization 
management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  the  solicitation  activities  at  an  appropriate 
level  of  abstraction.  The  reviews  verify  that  acquisition  organization  policy  is  being 
implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the  organization 
and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are 
available. _ 

Verification  2  Solicitation  activities  are  reviewed  by  the  project  manager  or  designated 
selection  official  on  both  a  periodic  and  event-driven  basis. 
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Requirements  Development  and  Management 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common  and 
unambiguous  definition  of  contractual  requirements  that  is  understood  by  the  project  team,  end 
user,  and  the  supplier  team.  Contractual  requirements  consist  of  technical  requirements  (e.g., 
system  requirements  allocated  to  products  and  their  evaluation  requirements)  and  non-technical 
requirements  (e.g.,  contractual  agreements,  conditions,  and  terms  affecting  the  acquisition).  This 
key  process  area  addresses  the  development  of  contractual  requirements  and  the  subsequent 
management  of  these  requirements  for  the  duration  of  the  acquisition. 

Requirements  development  involves  those  activities  in  which  contractual  requirements,  taking 
into  account  those  provided  by  the  end  user,  are  developed  and  documented.  To  ensure  software 
is  appropriately  addressed  during  product  requirements  definition  and  solicitation  package 
preparation,  the  software  management  personnel  participate  with  the  overall  acquisition  team. 
Reuse  of  existing  software  assets,  including  architecture,  is  analyzed  for  use  in  satisfying 
requirements.  Requirements  development  often  involves  direct  participation  from  the  end  user  to 
ensure  that  product  requirements  are  well  understood. 

Requirements  management  involves  establishing  and  maintaining  agreement  among  the  project 
team,  including  the  end  user,  and  supplier  team  with  respect  to  the  contractual  requirements.  It 
involves  baselining  the  requirements  and  controlling  all  subsequent  requirements  changes.  This 
key  process  area  and  the  contract  address  both  technical  and  non-technical  requirements. 

Requirements  development  and  management  begins  with  the  translation  of  operational  or  end 
user  requirements  into  solicitation  documentation  (e.g.,  specifications)  and  ends  with  the  transfer 
of  responsibility  for  the  support  of  the  products. 

Contractual  requirements  define  the  scope  of  the  effort.  Contractual  requirements  are 
incorporated  into  project  plans,  activities,  and  products  in  an  orderly  manner.  Requirements 
management  ensures  that  requirements  are  unambiguous,  traceable,  verifiable,  documented,  and 
controlled. 
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Goals 


Goal  1  Contractual  requirements  are  developed,  managed,  and  maintained. 

Goal  2  The  end  user  and  other  affected  groups  have  input  to  the  contractual 

requirements  over  the  life  of  the  acquisition. 

Goal  3  Contractual  requirements  are  traceable  and  verifiable. 

Goal  4  The  contractual  requirements  baseline  is  established  prior  to  release  of 

the  solicitation  package. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  establishing  and 
managing  the  contractual  requirements. 

1.  This  policy  typically  specifies  that: 

►  Contractual  requirements  are  documented. 

►  Contractual  requirements  are  reviewed  by: 

*  Project  management. 

*  Other  affected  groups. 

Some  examples  of  affected  groups  include: 
end  user, 

project  system  engineering, 
project  evaluation, 
project  quality  assurance, 
software  support  organization,  and 
project  configuration  and  data  management. 

►  Changes  to  the  contractual  requirements  are  reflected  in  acquisition  plans,  work 
products,  services,  and  activities. 

►  A  change  control  mechanism  exists  to  manage  and  control  changes  to  the  contractual 
requirements. 


“Managed  and  controlled”  implies  that  the  requirements  are  baselined,  the  version  of  the 
requirements  at  a  given  time  (past  or  present)  is  known  (i.e.,  version  control),  and  the  changes 
are  incorporated  in  a  controlled  manner  (i.e.,  change  control). _ 


2.  Requirements  include: 
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Commitment  2 

Ability  1 
Ability  2 


Ability  3 


►  Non-technical  requirements  (e.g.,  the  contractual  agreements,  conditions,  and  terms) 
that  affect  and  determine  the  activities  of  the  acquisition  project. 


Some  examples  of  contractual  agreements,  conditions,  and  terms  include: 

products  to  be  delivered, 
data  rights  for  delivered  COTS/ND  I, 
intellectual  property  rights, 
delivery  dates,  and 
milestones  with  exit  criteria. 


►  Technical  requirements. _ 

Some  examples  of  technical  requirements  include: 

functional  requirements, 
performance  requirements, 
security  requirements, 
quality  requirements, 
design  constraints, 
architectural  constraints, 
reuse  requirements, 
supportability  requirements, 
external  interface  requirements, 
evaluation  requirements,  and 
standards. 


Responsibility  for  requirements  development  and  management  is 
designated. 

Ability  to  perform 


A  group  that  performs  requirements  development  and  management 
activities  exists. 


Adequate  resources  are  provided  for  requirements  development  and 
management  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 


Tools  to  support  the  activities  for  managing  contractual  requirements  may  include: 

spreadsheet  programs, 
configuration  management  tools, 
traceability  tools, 
lexical  analysis  tools, 
specification  modeling  tools, 
evaluation  management  tools,  and 

prototyping  tools. _ 


Individuals  performing  requirements  development  and  management 
activities  have  experience  or  receive  training. 
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Experience  means,  for  example,  having  participated  in  an  acquisition  management  role 
on  at  least  one  project  and  having  experience  in  the  domain  of  the  application  being 
acquired.  _ _ 


Some  examples  of  training  include: 

the  methods,  standards,  and  procedures  used  by  the 
project; 

the  application  domain;  and 
architectures. 


Activities  performed 


Activity  1  The  project  team  performs  its  activities  in  accordance  with  its 

documented  requirements  development  and  management  plans  and 
procedures. 

The  plans  typically  cover: 

1.  The  objectives  of  the  project  team’s  requirements  development  and  management 
activities. 

2.  The  activities  to  be  performed,  including  requirements  definition. 

3.  Identification  of  the  groups,  and  intergroup  coordination,  associated  with  requirements 
development  and  management  activities. 

Some  examples  of  groups  include: 

potential  bidders, 
project  system  engineering, 
project  cost  analysis, 

project  configuration  and  data  management, 

project  evaluation, 

product-line  management, 

project  quality  assurance,  and 

end  user. _ 


4.  Procedures  for  requirements  development,  including  planning,  elicitation,  analysis,  and 
verification. 

5.  Procedures  for  requirements  management,  including  baseline  establishment,  change 
control,  and  status  reporting. 

6.  Procedures  to  define  attributes  that  describe  a  “satisfactory”  requirement. 


Some  examples  of  criteria  for  satisfactory  requirements  are: 
correcmess, 

completeness. _ _ 
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Activity  2 


Activity  3 
Activity  4 


consistency, 

clarity, 

non-ambiguity, 
verifiability, 
traceability,  and 
feasibility. 


7.  Procedures  for  impact  analysis  of  changes  to  requirements  or  introduction  of  new 
requirements,  including  performance,  cost,  and  schedule. 

8.  Resource  requirements  and  schedules  to  perform  requirements  development  and 
management  activities. 


Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  project  team  develops,  baselines,  and  maintains  contractual 
requirements  and  places  them  under  change  control  early  in  the  project, 
but  not  later  than  release  of  the  solicitation  package. 

1 .  Baselined  contractual  requirements  are  documented, 

2.  Contractual  requirements  are  reviewed  for  completeness,  understandability,  verifiability, 
and  priority. 

3.  Evaluation  and  acceptance  criteria  for  contractual  requirements  are  established  and 
controlled. 

4.  Changes  to  the  baseline  are  managed  and  controlled. 

The  project  team  appraises  change  requests  of  contractual  requirements 
for  their  impact  on  the  products  being  acquired. 

The  project  team  appraises  all  changes  to  the  requirements  for  their 
impact  on  performance,  architecture,  supportability,  system  resource 
utilization,  evaluation  requirements,  and  contract  schedule  and  cost. 

1.  The  impact  on  existing  commitments  is  determined  and  changes  in  commitments  are 
negotiated  as  appropriate. 

Some  examples  of  changes  include: 

Changes  to  commitments  made  to  individuals  and  groups  external  to  the  acquisition  organization 
and 

changes  to  commitments  within  the  acquisition  organization. _ 

2.  Changes  to  acquisition  plans,  products,  or  activities  resulting  from  changes  in  contractual 
requirements  are: 

►  Identified. 
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►  Appraised  for  potential  impact. 

►  Analyzed  for  risk. 

►  Documented. 

►  Communicated  to  the  affected  groups  and  individuals. 

►  Tracked  to  completion. 

Activity  5  Bi-directional  traceability  between  the  contractual  requirements  and  the 

supplier  team’s  products  is  maintained  throughout  the  effort. 

Some  examples  of  mechanisms  providing  this  traceability  include: 

Traceability  matrices,  and 

Requirements  tracing  tools. _ 

Activity  6  The  project  team  ensures  that  the  contracting  official,  end  user,  and  other 

affected  groups  are  involved  in  the  development  of  all  contractual 
requirements  and  any  subsequent  change  activity. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

requirements  development  and  management  activities  and  resultant 
products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  requirements  development  and  management 
planning,  the  initial  requirements,  and  baselining  the  requirements; 
number  of  change  requests  appraised;  and 

completion  of  milestones. _ 


Verifying  implementation 


Verification  1  Requirements  development  and  management  activities  are  reviewed  by 
acquisition  organization  management  (and  the  supplier)  on  a  periodic 
basis. 
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Verification  2 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  requirements  development  and  management 
activities  at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Requirements  development  and  management  activities  are  reviewed  by 
the  project  manager  on  both  a  periodic  and  event-driven  basis. 
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Project  Management _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  organizations  to  ensure  a  timely,  efficient,  and  effective  acquisition. 

Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling  project 
activities,  such  as  determining  project  tasks,  estimating  effort  and  cost,  scheduling  activities  and 
tasks,  training,  leading  the  assigned  personnel,  and  accepting  products. 

Project  management  begins  when  the  project  office  is  officially  chartered  and  terminates  when 
the  acquisition  is  completed. 

Goals 


Goal  1  Project  management  activities  are  planned,  organized,  controlled,  and 

communicated. 

Goal  2  The  performance,  cost,  and  schedule  of  the  acquisition  project  are 

continually  measured,  compared  to  planned  objectives,  and  controlled 
throughout  the  acquisition. 

Goal  3  Problems  discovered  during  the  acquisition  are  managed  and  controlled. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  execution  of  the 
project. 

This  policy  typically  specifies  that: 

1.  The  requirements  are  used  as  the  basis  for  planning  the  acquisition  project. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

2.  The  acquisition  project’s  commitments  are  coordinated  among  the  affected  managers. 

3.  Involvement  of  other  affected  groups  in  the  acquisition  activities  is  negotiated  and 
documented. 
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Commitment  2 

Ability  1 
Ability  2 


Ability  3 


Some  examples  of  affected  groups  include: 

operational  test  group, 

system  engineering  group, 

software  engineering  group,  and 

end  user  representatives. _ 


4.  Acquisition  organization  management  reviews  all  project  commitments  made  to 
individuals  and  groups  external  to  the  organization. 

5.  The  project’s  acquisition  plans  are  managed  and  controlled. 

6.  A  corrective  action  system  is  to  be  established  by  the  project  team  to  record  problems  and 
issues  discovered. 

Responsibility  for  project  management  is  designated. 

Ability  to  perform 


A  team  that  performs  the  project’s  acquisition  management  activities 

exists. 

Adequate  resources  for  the  project  team  are  provided  for  the  duration  of 

the  acquisition  project. 

1.  The  project  office  allocates  sufficient  funds  for  internal  operations,  matrix  support, 
contractual  efforts,  and  specific  mission  areas  of  responsibility. 

2.  The  project  office  is  staffed  with  the  proper  number  and  kinds  of  people  to  address 
internal  responsibilities  and  matrix  support  needed  to  accomplish  the  project’s  activities, 

3.  The  project  office  plans  for  and  provides  the  equipment  needed  to  accomplish  the 
project’s  activities. 

4.  The  project  office  plans  for  and  provides  the  tools  needed  to  accomplish  the  project’s 
activities. 


The  project  team  has  experience  or  receives  training  in  project 
acquisition  management  activities. 


Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project  and  having  experience  in  the  domain  of  the  application 
being  acquired.  Additionally,  some  individuals  should  have  general  management 
skills  as  well  as  budgeting  and  scheduling  experience. _ 
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Activities  performed 


Activity  1 


Activity  2 


Activity  3 


Activity  4 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  acquisition  management  plans  and  procedures. 

Project  acquisition  management  plans  typically  contain  or  reference  documents  that  contain: 

1.  Project  objectives,  purpose,  scope,  and  duration. 

2.  Project  summary  and  authorization. 

3.  Project  team  structure,  roles,  and  responsibilities. 

4.  Resource  requirements. 

5.  Acquisition  strategy. 

6.  Project  performance,  cost,  and  schedule  baselines. 

7.  Coordination  and  communication. 

8.  Risk  identification  and  tracking. 

9.  Relationship  to  systems  and  software  engineering. 

10.  Installation  of  the  Software  Engineering  Environment  and  other  products  of  the 
contract. 

1 1.  Integrated  logistics  support  requirements. 

12.  Software  support  requirements. 

13.  Security  policy  and  requirements. 

14.  Corrective  action  reporting  procedures. 

15.  The  extent  of  end  user  involvement  in  the  acquisition. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  roles,  responsibilities,  and  authority  for  the  project  functions  are 
documented,  maintained,  and  communicated  to  affected  groups. 

The  project  team’s  commitments,  and  changes  to  commitments,  are 
communicated  to  affected  groups. 

The  project  team  tracks  the  risks  associated  with  cost,  schedule, 
resources,  and  the  technical  aspects  of  the  project. 
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1.  The  priorities  of  the  risks  and  the  contingencies  for  the  risks  are  adjusted  as  additional 
information  becomes  available. 

2.  High-risk  areas  are  reviewed  with  acquisition  organization  management  on  a  regular 
basis. 


Activity  5  The  project  team  tracks  project  issues,  status,  execution,  funding,  and 

expenditures  against  project  plans  and  takes  action. 

Activity  6  The  project  team  implements  a  corrective  action  system  for  the 

identiflcation,  recording,  tracking,  and  correction  of  problems  discovered 
during  the  acquisition. 

Activity  7  The  project  team  keeps  its  plans  current  during  the  life  of  the  project  as 

replanning  occurs,  issues  are  resolved,  requirements  are  changed,  and 
new  risks  are  discovered. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  project 
management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  project  management 
planning  and  the  organizational  strategy,  and 
completion  of  milestones. _ 
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Verifying  implementation 


Verification  1  Project  management  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  management  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Verification  2  Project  management  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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Contract  Tracking  and  Oversight _ 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  activities  under  contract  are 
being  performed  in  accordance  with  contractual  requirements. 

Contract  Tracking  and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the 
supplier’s  effort  and  identifying  risks  and  problems  in  the  effort. 

Contract  tracking  and  oversight  begins  with  the  award  of  the  contract  and  ends  at  the  conclusion 
of  the  contract’s  period  of  performance. 

The  contract  provides  the  binding  agreement  for  establishing  the  requirements  for  the  products  to 
be  acquired.  It  establishes  the  mechanism  to  allow  the  project  team  to  oversee  the  supplier 
team’s  activities  and  evolving  products  and  to  evaluate  any  product  being  acquired.  It  also 
provides  the  vehicle  for  mutual  understanding  between  the  project  team  and  the  supplier  of  the 
requirements  of  the  contract. 

Goals 


Goal  1  The  project  team  has  sufficient  insight  into  the  supplier’s  activities  to 

ensure  the  effort  is  managed  and  controlled  and  complies  with  contract 
requirements. 

Goal  2  The  project  team  and  supplier  team  maintain  ongoing  communication 

and  commitments  are  agreed  to  and  implemented  hy  both  parties. 

Goal  3  All  changes  to  the  contract  are  managed  throughout  the  life  of  the 

contract. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  contract 
tracking  and  oversight  of  the  contracted  effort. 

This  policy  typically  specifies  that: 
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1.  Planning  for  contract  tracking  and  oversight  is  documented. 

2.  Contract  tracking  and  oversight  plans  are  managed  and  controlled. 

3.  Applicable  tools  and  methodologies  are  to  be  used  to  track  the  contracted  effort. 

4.  The  integrity  of  the  contract  is  to  be  maintained  throughout  the  contract  performance 
period. 

5.  Required  efforts  are  to  be  addressed  at  reviews  of  supplier  team  performance. 

Commitment  2  Responsibility  for  contract  tracking  and  oversight  activities  is  designated. 

Commitment  3  The  project  team  includes  contracting  specialists  in  the  execution  of  the 
contract. 

Ability  to  perform 


Ability  1 
Ability  2 


Ability  3 


A  group  that  performs  the  management  of  contract  tracking  and 
oversight  activities  exists. 

Adequate  resources  are  provided  for  contract  tracking  and  oversight 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  contract  tracking  and  oversight  activities  have 
experience  or  receive  training. 


Experience  means,  for  example,  having  participated  on  at  least  one  project  in  areas  of 
tracking  development  under  contract,  providing  technical  guidance  to  suppliers,  and 
correctly  applying  contractual  and  legal  policies  and  regulations  for  that  effort. _ 


Activities  performed 


Activity  1  The  project  team  performs  its  activities  in  accordance  with  its 

documented  contract  tracking  and  oversight  plans  and  procedures. 

The  plans  typically  cover: 

1 .  Guidelines  and  criteria  used  in  defining  the  project  team’s  contract  tracking  and  oversight 
activities. 
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2.  Activities  to  be  performed  and  the  schedule  to  perform  these  activities. 

3.  Identification  of  groups,  assigned  responsibilities,  and  intergroup  coordination. 

4.  End  user  involvement. 

5.  Techniques,  tools,  and  methodologies  to  be  employed  for  review  and  tracking  of  supplier 
team  performance  and  compliance  of  the  evolving  products. 

6.  Resources  required  to  accomplish  contract  tracking  and  oversight  activities. 

7.  Procedures  to  be  followed  to  track  and  identify  issues  to  closure. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

Activity  2  The  project  team  reviews  required  supplier  planning  documents  which, 

when  satisfactory,  are  used  to  oversee  the  supplier’s  effort 


Changes  to  these  plans  are  to  be  coordinated  with  the  project  team  before  being 
implemented  by  the  supplier  team. _ 


Some  examples  of  supplier  planning  documents  that  may  be 
required  include: 
project  management, 
risk  management, 
engineering, 
reuse, 

configuration  management,  and 

subsupplier  management. _ 

Activity  3  The  project  team  conducts  periodic  reviews  and  interchanges  with  the 

supplier  team. 

These  reviews  may  include  end  user  and  other 
affected  groups  input  as  needed. _ 

These  reviews  typically  attempt  to  ensure: 

1.  Continuing  communications  and  mutual  understanding  of  the  contractual  requirements. 

2.  The  supplier  team  is  implementing  activities  according  to  approved  plans. 

3.  Open  issues  with  the  supplier  are  resolved. 

4.  The  supplier’s  activities  and  results  are  addressed. 

5.  The  supplier  team’s  evaluations  of  the  products  comply  with  approved  evaluation  plans 
and  procedures. 

6.  The  supplier’s  corrective  action  system,  including  deficiency  reporting,  deficiency 
correction,  re-testing,  and  rework,  is  being  implemented  according  to  approved  plans  and 
procedures. 
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Level  2:  The  Repeatable  Level 


Activity  4 


Activity  5 


Activity  6 


Activity  7 


7.  Evolving  products  will  satisfy  contractual  non-technical  and  technical  requirements, 
including  functional,  performance,  operational,  supportability,  and  other  quality 
requirements. 

Refer  to  the  Evaluation  key  process  area  for  evaluation  of  evolving  products. 

8.  Issues  are  identified  and  plans  developed  for  their  resolution. 

The  actual  cost  and  schedule  of  the  supplier’s  effort  are  compared  to 
planned  schedules  and  budgets  and  issues  are  identified. 


Some  examples  of  supplier  team  progress 
tracking  include: 

contract  work  packages, 
periodic  progress  measurements, 
earned  value  practices,  and 
performance  assessments. _ 


The  technical  activities  associated  with  the  supplier  team’s  products  are 
tracked,  compared  to  plans,  and  issues  identified. 

The  project  team  reviews  and  tracks  the  development  of  the  software 
engineering  environment  required  to  provide  life  cycle  support  for  the 
acquired  products  and  issues  are  identified. 

Any  issues  found  by  the  project  team  during  contract  tracking  and 
oversight  are  recorded  in  the  appropriate  corrective  action  system,  action 
taken,  and  tracked  to  closure. 


The  appropriate  corrective  action  system  can  be  either  the  project  team’s  or  the 
supplier’s. _ 
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Contract  Tracking  and  Oversight 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
tracking  and  oversight  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  contract  tracking  and  oversight  planning  and 
baselining  supplier  planning  documents, 

number  of  items  closed  in  the  corrective  action  system  used  by  the  project  team, 
and 

completion  of  milestones.  _ _ 


Verifying  implementation 


Verification  1 


Contract  tracking  and  oversight  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  tracking  and  oversight  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available.  _ _ 


Verification  2 


Contract  tracking  and  oversight  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Evaluation 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Evaluation  is  to  provide  objective  evidence  that  the  evolving  products  satisfy 
contractual  requirements  prior  to  acceptance. 

Evaluation  involves  the  development  of  requirements  for  the  evaluation  approach,  including 
acceptance  criteria,  which  are  incorporated  into  both  the  solicitation  package  and  the  contract. 
Evaluations  of  the  evolving  products  by  both  the  supplier  and  project  team  are  routinely 
conducted  throughout  the  entire  contract  performance  period  and  results  are  analyzed  to 
determine  acceptability  of  the  products.  Project  team  evaluation  activities  are  designed  to  reduce 
interference  with  supplier-performed  evaluations  and  to  reduce  duplication  of  the  supplier’s 
evaluation  efforts.  Evaluation  supports  the  activities  that  establish  and  verify  the  contractual 
requirements.  Evaluation  interacts  with  the  Solicitation,  Requirements  Development  and 
Maintenance,  and  Contract  Tracking  and  Oversight  key  process  areas. 

Evaluation  begins  with  development  of  the  products’  requirements  and  ends  when  the  acquisition 
is  completed. 


Goals 


Goal  1  Evaluation  requirements  are  developed  in  conjunction  with  the 

contractual  requirements  and  are  maintained  over  the  life  of  the 
acquisition. 

Goal  2  Evaluations  are  planned  and  conducted  throughout  the  total  period  of  the 

acquisition  to  provide  an  integrated  approach  that  satisHes  evaluation 
requirements  and  takes  advantage  of  all  evaluation  results. 

Goal  3  Evaluations  provide  an  objective  basis  to  support  the  decision  for 

acceptance  of  the  products. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  managing  the 
evaluation  of  the  acquired  products. 

This  policy  typically  specifies  that: 
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Evaluation 


Commitment  2 


Ability  1 


Ability  2 


1.  Evaluations  are  intended  to  reduce  acquisition  risk  and  to  estimate  effectiveness  and 
suitability  of  the  product  to  support  the  satisfaction  of  end  user  needs. 

2.  The  project  includes  plans  for  the  evaluation  of  the  acquired  products  that  specify 
evaluation  objectives  and  evaluation  criteria. 

3.  The  project’s  evaluation  activities  begin  with  the  development  of  the  contractual 
requirements. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

4.  The  project  defines  the  evaluation  requirements  for  the  acquisition. 


Some  examples  of  evaluation  requirements  include: 

documented  evaluation  approach  involving  the  project  team,  supplier  team,  and  other  affected  roups; 
supplier  evaluation  activities,  or  tasks  required; 
supplier  deliverables  and  reports;  and 
evaluation  schedule. 


5.  Results  of  the  evaluations  are  used  as  a  basis  for  acceptance  of  the  products. 

6,  The  project’s  evaluation  planning  is  updated  to  reflect  changes  to  the  requirements. 

Responsibility  for  evaluation  activities  is  designated. 

Ability  to  perform 


A  group  that  plans,  manages,  and  performs  the  evaluation  activities  for 
the  project  exists. 

The  evaluation  group  may  include: 

1 .  Independent  evaluators. 

2.  End  users. 

3.  Support  organization. 

4.  System  and  software  engineers. 

5.  Members  of  the  requirements  development  and  management  group. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

Adequate  resources  are  provided  for  evaluation  activities. 
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Ability  3 


Ability  4 


Activity  1 


Resources  include  funding,  staff,  equipment,  and  tools. 


Some  examples  of  tools  to  support  evaluation  activities  include: 

data  collection  tools. 

test  environments, 

static  code  analyzers, 

problem  tracking  software  packages, 

configuration  management  tools,  and 

traceability  tools. _ 


Individuals  performing  evaluation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  developed  methods  for  the  evaluation  of 
products,  having  applied  basic  analysis  techniques,  and  having  evaluated  product 
quality  data  on  at  least  one  project. _ 


Members  of  the  project  team  and  groups  supporting  the  acquisition 
receive  orientation  on  the  objectives  of  the  evaluation  approach. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  evaluation  plans  and  procedures. 

The  plans  typically  cover: 

1.  A  summary  of  the  operational  need  and  key  operational  effectiveness  or  suitability  issues 
that  must  be  addressed  by  evaluation. 

2.  A  brief  description  of  the  system  and  key  areas  of  technical  or  engineering  risk  that  must 
be  addressed  by  evaluation. 

3.  A  brief  description  of  the  integrated  evaluation  approach,  including  evaluation  objectives, 
the  evaluation  activities  to  be  performed,  and  the  integrated  schedule  for  these  activities. 

4.  The  groups  responsible  for  conducting  evaluation  activities. 

5.  A  summary  of  the  resources  required  to  perform  the  evaluations. 

6.  The  actions  to  be  taken  when  product  quality  is  determined  or  projected  to  fall  short  of 
established  requirements. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 
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Evaluation 


Activity  2 


Activity  3 

Activity  4 
Activity  5 


Measurement  1 


The  project’s  evaluation  requirements  are  developed  in  conjunction  with 
the  development  of  the  contractual  requirements. 

1.  Development  of  evaluation  requirements  involves  groups  participating  in  evaluation 
activities,  including  the  end  users. 

2.  Development  of  evaluation  requirements  may  involve: 

►  Identifying  the  contractual  requirements  to  be  evaluated. 

►  Identifying  architectural  compliance  issues  to  be  evaluated. 

►  Establishing  objective  evaluation  and  acceptance  criteria. 

►  Designing  detailed  activities  to  perform  the  evaluations. 

►  Identifying  how  to  evaluate  the  quality  of  the  acquired  products. 

►  Identifying  requisite  resources  and  ensuring  that  these  resources  will  be  in  place. 

►  Developing  a  detailed  schedule  of  activities. 

►  Ensuring  traceability  of  evaluation  requirements  to  product  requirements. 

The  project’s  evaluation  activities  are  planned  to  minimize  duplication  of 
the  supplier’s  evaluation  efforts  and  take  advantage  of  the  evaluation 
results,  where  appropriate. 

Planned  evaluations  are  performed  on  the  evolving  products. 

Results  of  the  evaluations  are  analyzed  and  compared  to  the  contract’s 
requirements  to  establish  an  objective  basis  to  support  the  decision  to 
accept  the  product  or  to  take  further  action. 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
evaluation  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
effort  expended, 
funds  expended, 

progress  towards  completion  of  evaluation 
planning  and  of  evaluation  requirements,  and 
completion  of  milestones. _ 
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Verification  1  Evaluation  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  evaluation  activities  at  an  appropriate  level  of 
abstraction.  The  reviews  verify  that  acquisition  organization  policy  is  being 
implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the  organization 
and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are 
available. _ 

Verification  2  Evaluation  activities  are  reviewed  by  the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
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Transition  to  Support _ _ _ 

a  key  process  area  for  Level  2:  Repeatable  _ 


The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  products  being 
acquired  to  the  eventual  support  organization.  The  necessary  resources  are  identified,  budgeted 
for,  and  are  available  when  needed.  The  designated  support  organization  is  fully  prepared  to 
accept  responsibility  for  the  products  in  time  to  ensure  uninterrupted  support. 

Transition  to  Support  involves  developing  and  implementing  the  plans  for  transitioning  the 
acquired  products.  It  also  involves  ensuring  that  the  supplier  team  and  the  support  organization 
are  informed  on  the  contents  of  the  software  engineering  and  support  environments.  The  project 
team  provides  for  an  orderly,  smooth  transition  of  the  products  from  the  supplier  team  to  the 
support  organization. 

Transition  to  support  begins  with  the  earliest  definition  of  requirements  and  ends  when  the 
responsibility  for  the  products  is  turned  over  to  the  support  organization. 


Goals 


Goal  1  The  project  team  ensures  the  support  organization  has  the  capacity  and 

capability  to  provide  the  required  support  upon  assumption  of 
responsibility  for  the  support  of  the  acquired  products. 

Goal  2  There  is  no  loss  in  continuity  of  support  to  the  products  during  transition 

from  the  supplier  to  the  support  organization. 

Goal  3  Conflguration  management  of  the  products  is  maintained  throughout  the 

transition. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  transitioning  of 
products  to  the  support  organization. 

This  policy  typically  specifies  that: 

1.  The  support  organization  is  identified  prior  to  developing  the  solicitation  package. 
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2.  Resources  for  support  are  included  in  the  appropriate  budget{s), 

3.  The  designated  support  organization  is  involved,  as  appropriate,  throughout  the 
acquisition. 

Commitment  2  The  acquisition  organization  ensures  that  the  support  organization  is 
involved  in  planning  for  transition  to  support. 

Commitment  3  Responsibility  for  transition  to  support  activities  is  designated. 

Ability  to  perform 


Ability  1  A  group  that  performs  the  coordination  of  transition  to  support  activities 

exists. 


Ability  2 


Ability  3 


Ability  4 


Ability  5 


Adequate  resources  are  provided  for  transition  to  support  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

The  organization  responsible  for  providing  support  of  the  products  is 
identified  early  in  the  project  planning  process  so  that  life  cycle 
supportability  issues  and  requirements  can  be  accommodated  in  the 
project’s  requirements. 

The  support  organization,  prior  to  transition,  has  a  complete  inventory  of 
all  products  and  related  items  that  are  to  be  transitioned. 


Some  examples  of  related  items  include: 

software  descriptive  documentation, 
necessary  support  software, 
reusable  software  assets, 
pertinent  data  from  the  corrective  action 
and  configuration  management  systems, 
and 

maintenance  documentation. 


Individuals  performing  transition  to  support  activities  have  experience  or 
receive  training. 


Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project  and  having  participated  in  supporting  hardware  and 
software  for  at  least  two  years. _ 
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Transition  to  Support 


Ability  6 


Activity  1 


Activity  2 


The  members  of  organizations  interfacing  with  the  transition  to  support 
activities  receive  orientation  on  the  salient  aspects  of  transition  to  support 
activities. 

Activities  performed 

The  project  team  performs  its  activities  in  accordance  with  its 
documented  transition  to  support  plans. 

The  plans  typically  cover: 

1 .  The  objectives  and  scope  of  the  transition  to  support  activities. 

2.  Identification  and  involvement  of  the  support  organization. 

3.  Support  resource  requirements. 

4.  A  definition  of  transition  activities. 

5.  A  schedule  of  transition  activities. 

6.  Allocation  of  transition  responsibilities. 

7.  Installation  of  products  that  are  to  be  delivered. 

8.  Warranty  and  data  rights  provisions. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

Responsibility  for  the  products  is  transferred  only  after  the  support 
organization  demonstrates  its  capability  and  capacity  to  modify  and 
support  the  products. 

This  capability  typically  includes  the  availability  of: 

1.  Hardware,  software,  physical,  fiscal,  and  personnel  resources. 

2.  Plans,  processes,  procedures,  and  documentation. 

3.  An  established  configuration  management  system  capable  of  supporting  the  products. 

4.  Appropriate  training  of  all  personnel  involved. 

5.  Software  replication,  test,  and  distribution  capabilities. 
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Activity  3 


Activity  4 


Measurement  1 


Verification  1 


I 

i 

Verification  2 


The  project  team  conducts  activities  to  ensure  that  support  of  the 
products  is  maintained  and  is  effective  during  the  transition  from  the 
supplier  to  the  support  organization. 

The  project  team  oversees  the  configuration  control  of  the  products 
throughout  the  transition. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
transition  to  support  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  transition 

to  support  planning,  and 

completion  of  milestones. _ 


Verifying  implementation 


Transition  to  support  activities  are  reviewed  by  acquisition  and  support 
organizations’  managements  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  and  software  support 
organizations’  management  is  to  provide  awareness  of,  and  insight  into,  transition  to 
support  activities  at  an  appropriate  level  of  abstraction.  The  reviews  verify  that 
acquisition  organization  policy  is  being  implemented.  The  time  between  reviews 
should  satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate 
mechanisms  for  exception  reporting  are  available. _ 


Transition  to  support  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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At  the  Defined  Level,  the  acquisition  organization’s  standard  acquisition  process  is  established, 
including  the  processes  for  both  contract  management  and  project  management,  and  its  use  is 
integrated  into  each  project.  The  acquisition  organization  exploits  effective  acquisition 
techniques  when  standardizing  acquisition  processes.  There  is  a  permanent  focus  on  the  process; 
the  acquisition  organization’s  process  improvement  group  facilitates  process  definition  and 
maintenance  efforts.  Processes  established  at  the  Defined  Level  are  adapted  from  the  standard 
acquisition  process  as  appropriate  to  perform  more  effectively  within  the  project.  A  training 
program  is  implemented  to  ensure  that  all  practitioners  and  managers  have  the  knowledge  and 
skills  required  to  carry  out  their  tasks. 

Projects  use  the  acquisition  organization’s  standard  acquisition  process  as  a  basis  for  creating 
their  own  defined  acquisition  process  that  encompasses  the  unique  characteristics  of  the  project. 
Because  the  acquisition  organization’s  standard  acquisition  process  is  well  defined  and 
understood,  management  has  good  visibility  into  technical  progress  of  the  project.  Management 
and  engineering  activities  are  coherently  integrated  on  each  project.  When  attempting  to  comply 
with  required  policy,  the  project  team  is  capable  of  balancing  the  intent  of  the  policy  with  a 
conflicting  project  need.  The  project  team  ensures  compliance  with  plans  and  contract 
requirements  and  works  with  the  supplier  to  resolve  compliance  difficulties  when  they  arise. 
Risks  are  identified  and  managed  throughout  the  acquisition. 

The  process  capability  of  Level  3  acquisition  organizations  can  be  summarized  as  being 
controlled,  since  performance,  cost,  schedule,  and  requirements  are  under  control  and  quality  is 
tracked.  This  capability  is  based  on  a  common  understanding  of  processes,  roles,  and 
responsibilities  in  a  defined  acquisition  process. 

Level  3  key  process  areas  are: 

Process  Definition  and  Maintenance 
User  Requirements 
Project  Performance  Management 
Contract  Performance  Management 
Acquisition  Risk  Management 
Training  Program  Management 
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Level  3;  The  Defined  Level 


Process  Definition  and  Maintenance 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisition  organization’s 
standard  acquisition  process  and  an  organizational  responsibility  for  stabilizing  and  maintaining 
the  standard  acquisition  process. 

Process  Definition  and  Maintenance  involves  understanding  the  organization’s  and  projects’ 
acquisition  processes,  collecting  a  set  of  acquisition  process  assets,  and  coordinating  efforts  to 
appraise  and  improve  acquisition  processes. 

The  acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish  and 
maintain  a  process  improvement  group.  This  group  is  responsible  for  the  definition, 
maintenance,  and  improvement  of  the  acquisition  organization’s  standard  acquisition  process  and 
other  process  assets,  including  guidelines  for  all  projects  to  adapt  the  standard  acquisition  process 
to  their  specific  situations.  It  coordinates  process  activities  with  the  projects  and  related  elements 
of  the  organization. 

Goals 


Goal  1  A  standard  acquisition  process  for  the  acquisition  organization  is  deHned, 

managed,  and  controlled. 

Goal  2  Process  definition  and  maintenance  activities  are  coordinated  across  the 

acquisition  organization. 

Goal  3  Information  relating  to  the  use  of  the  acquisition  organization’s  standard 

acquisition  process  by  the  acquisition  projects  is  collected,  analyzed,  and 
made  accessible. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  acquisition  process 
definition  and  maintenance  activities. 

This  policy  typically  specifies  that: 
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Process  Definition  and  Maintenance 


1.  A  process  improvement  group  is  established  and  is  responsible  for  the  acquisition 
organization-level  acquisition  process  activities  and  coordinating  these  activities  with  the 
projects. 

2.  A  standard  acquisition  process  is  defined  for  the  acquisition  organization. 

The  acquisition  organization’s  standard  acquisition  process  may  contain  more  than  one  process.  A 
choice  of  processes  may  be  necessary  to  address  a  project’s  unique  acquisition  environment. _ 

3.  The  acquisition  process  used  by  the  projects  is  adapted  from  the  acquisition 
organization’s  standard  acquisition  process  and  is  based  on  a  project’s  specific  acquisition 
environment. 

4.  The  acquisition  process  assets  are  maintained. 

The  acquisition  organization’s  acquisition  process  assets  include: 
the  acquisition  organization’s  standard  acquisition  process, 

guidelines  and  criteria  for  the  projects’  adaptation  of  the  acquisition  organization’s  standard 
acquisition  process, 

descriptions  of  the  standard  acquisition  strategies  approved  for  use,  and 

the  acquisition  process  repository.  _ 

5.  Improvements  to,  lessons  learned,  and  other  useful  information  on  each  project’s  defined 
acquisition  process,  tools,  and  methods  are  collected  and  made  accessible  to  other 
projects. 

6.  Information  collected  from  the  projects  is  reviewed,  analyzed,  and  used  to  improve  the 
acquisition  organization’s  standard  acquisition  process. 

Commitment  2  Organization  management  sponsors  the  acquisition  organization’s 
activities  for  process  definition  and  maintenance. 

Organization  management  establishes: 

1.  Long-term  plans  and  commitments  for  funding,  staffing,  and  other  resources,  and  its 
commitment  to  these  acquisition  process  activities. 

2.  Strategies  for  managing  and  implementing  the  activities  for  process  definition  and 
maintenance. 

Commitment  3  Responsibility  for  process  definition  and  maintenance  activities  is 
designated. 

Ability  to  perform 


Ability  1  A  group  that  performs  the  acquisition  organization’s  process  definition 

and  maintenance  activities  exists. 
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Adequate  resources  are  provided  for  process  definition  and  maintenance 
activities. 

Resources  include  funds,  staff,  equipment,  and  tools. 

Members  of  the  acquisition  process  improvement  group  have  experience 
or  receive  required  training. 

Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project  and  membership  in  an  active  process  improvement  group, 
such  as  an  engineering  process  improvement  group,  for  at  least  one  year. _ 

Ability  4  Project  team  members  receive  training  on  the  acquisition  organization’s 

standard  acquisition  process  and  their  roles  in  this  process. 

Refer  to  the  Training  Program  key  process  area. 

Activities  performed 


Activity  1  The  acquisition  organization  performs  its  activities  in  accordance  with  its 

documented  process  definition  and  maintenance  plans. 


Ability  2 


Ability  3 


The  plan(s)  should  be  consistent  with  other  acquisition  organization  plans.  Inputs, 
such  as  action  plans  from  acquisition  process  appraisals,  strategic  and  operational 
business  plans,  and  acquisition  organization  improvement  initiatives,  should  be 
considered  in  the  development  of  and  subsequent  updates  to  the  plan. _ 


The  plans  typically  cover: 

1.  The  objectives  of  the  acquisition  organization’s  process  definition  and  maintenance 
activities. 


Objectives  define  the  direction  and  general  timing  for  the  acquisition  organization’s  process  definition 
and  maintenance  activities.  Objectives  may  specify  particular  areas  for  improvement  focus,  such  as 
contract  performance  management  and  procedural  guidance  and  the  coverage  and  time  intervals  for 
periodic  appraisals  of  the  acquisition  process.  _ 

2.  The  process  definition  and  maintenance  activities  to  be  performed  and  the  schedule  for 
these  activities. 

3.  The  groups  and  individuals  responsible  for  the  process  definition  and  maintenance 
activities. 

4.  The  resources  required  to  perform  the  process  definition  and  maintenance  activities, 

5.  The  procedures  to  be  followed  in  performing  the  process  definition  and  maintenance 
activities. 


L3-4 


CMU/SEI^2002-TR-010 


Level  3:  The  Defined  Level 


Process  Definition  and  Maintenance 


Activity  2 


Activity  3 


Activity  4 


6.  A  required  review  and  approval  by  acquisition  organization  management. 

7.  Management  and  control  of  the  plan(s). 

Refer  to  Activity  4  of  the  Acquisition  Planning  key  process  area. 


The  acquisition  organization’s  standard  acquisition  process  is  defined 
and  maintained  in  accordance  with  its  documented  process  definition  and 
maintenance  plans. 

These  plans  typically  require  that: 

L  The  acquisition  organization’s  standard  acquisition  process  satisfies  the  acquisition 
policies,  process  standards,  product  standards,  and  legal  requirements  imposed  on  the 
organization,  as  appropriate. 

2.  State-of-the-practice  acquisition  tools  and  methods  are  incorporated  into  the  acquisition 
organization’s  standard  acquisition  process,  as  appropriate. 

3.  A  cost  model(s)  for  project  planning  and  estimating  is  developed  and  maintained  as  part 
of  the  acquisition  organization’s  standard  acquisition  process. 

The  cost  model(s)  include  a  cost  model(s)  for  estimating  the  supplier’s  effort,  schedule,  and  cost;  a 
model(s)  for  estimating  the  project  team’s  effort,  schedule,  and  cost;  and  a  software  cost  model(s)  for 
estimating  life  cycle  cost. _ 

4.  The  acquisition  process  improvement  group  reviews,  approves,  manages,  and  controls 
any  changes  to  the  standard  acquisition  process. 

The  acquisition  organization’s  standard  acquisition  process  is  appraised 
periodically  and  action  plans  developed  and  implemented  to  address  the 
findings  of  the  appraisal. 

The  action  plans  typically  identify: 

1.  Which  appraisal  findings  will  be  addressed,  their  priority,  and  the  schedule  for  addressing 
them. 

2.  Guidelines  for  implementing  changes  to  address  the  findings. 

3.  Responsibility  for  implementing  the  changes. 

4.  Closure  plans  for  implementing  the  changes. 

5.  Appraisal  findings  that  will  not  be  addressed  and  rationale  for  not  doing  so. 

The  acquisition  organization’s  and  projects’  activities  for  deHning  and 
maintaining  their  acquisition  processes  are  coordinated  at  the 
organization  level. 
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Activity  5  Guidelines  and  criteria  for  a  project’s  adaptation  of  the  acquisition 

organization’s  standard  acquisition  process  are  developed  and 
maintained. 

The  guidelines  and  criteria  typically  cover: 

1.  Selecting  and  adapting  the  acquisition  organization’s  standard  acquisition  process  and 
acquisition  strategy  to  accommodate  the  project’s  characteristics. 

2.  Standards  for  documenting  the  project’s  defined  acquisition  process. 

3.  Procedures  for  obtaining  permission  to  deviate  from  the  acquisition  organization’s 
standard  acquisition  process. 

Activity  6  An  organizational  repository  of  acquisition  process  information  is 

established,  managed,  controlled,  and  maintained  to  support  process 
definition  and  maintenance  activities. 

1.  Information  includes  data  about  the  acquisition  process,  work  products,  acquisition 
process-related  documentation,  and  lessons  learned. 


Acquisition  process  and  work  products  data  include; 
cost  model  used; 

project  measurements  (planned  and  actual);  and 

software  size,  effort,  schedule,  and  deficiencies. _ 

Some  examples  of  acquisition  process-related  documentation  include; 

description  of  a  project’s  defined  acquisition  process  and 
a  project’s  acquisition  documentation  (e.g.,  acquisition  strategy, 
evaluation,  solicitation,  and  acquisition  management  plans). _ 

2.  Information  on  the  acquisition  organization’s  and  projects’  acquisition  processes  and 
work  products  is  collected. 

3.  Candidate  information  items  are  reviewed  and  appropriate  items  are  included  in  the 
repository. 

4.  Information  items  are  catalogued  for  easy  access. 

5.  The  repository  contents  are  made  available  for  use  by  the  acquisition  projects  and  other 
acquisition-related  groups. 

6.  The  use  of  each  information  item  is  reviewed  periodically  for  currency,  relevancy,  and 
validity,  and  the  results  are  used  to  maintain  the  repository  contents. 

7.  User  access  to  the  repository  contents  is  controlled  to  ensure  completeness,  integrity,  and 
accuracy  of  the  information. 

8.  Access  is  limited  to  those  who  have  a  need  to  enter,  change,  view,  analyze,  or  extract 
information.  Sensitive  information  is  protected  and  access  to  this  information  is 
appropriately  controlled. 
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Activity  7  Project  teams  are  informed  of  the  acquisition  organization’s  activities  for 

process  definition  and  maintenance  and  of  the  projects’  adaptations  of 
the  acquisition  organization’s  standard  acquisition  process. 

Some  examples  of  means  to  inform  project  teams  include: 

electronic  bulletin  boards  relating  to  acquisition 
process, 

working  groups, 

information  exchange  meetings, 

surveys, 

process  improvement  teams,  and 
informal  discussions. 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  process 
deflnition  and  maintenance  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 

completion  of  milestones. _ _ 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  process  definition  and  maintenance  capability. 


Some  examples  of  measurements  include: 

effort  expended, 

time  expended,  and 

funds  expended. _ 


Verifying  implementation 


Verification  1  Process  definition  and  maintenance  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  process  definition  and  maintenance  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 
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At  a  minimum,  these  reviews  verify  that: 

1.  Progress  and  status  of  the  activities  to  define  and  improve  the  acquisition  process  are 
reviewed  against  the  plan. 

2.  Conflicts  and  issues  not  resolved  at  lower  levels  are  addressed. 

3.  Action  items  are  assigned,  reviewed,  and  tracked  to  closure. 

4.  A  summary  report  from  each  review  is  prepared  and  distributed  to  affected  groups  and 
individuals. 
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User  Requirements 


User  Requirements _ _ 

A  key  process  area  for  Level  3:  Defined _ _ 

The  purpose  of  User  Requirements  is  to  elicit,  analyze,  translate,  and  communicate  end  user 
requirements  to  obtain  a  better  understanding  of  what  is  to  be  acquired. 

User  requirements  activities  involve  engaging  the  end  user  or  the  end  user’s  representative  in 
ongoing  dialogue,  eliciting  inputs  into  the  development  and  management  of  the  acquisition’s 
requirements.  These  requirements  provide  the  basis  for  understanding  and  agreement  between 
the  end  user,  the  acquisition  project  team,  and  the  contractor  team. 

End  user  needs  typically  change  over  time.  Project  teams  need  to  have  a  feasible  way  to 
incorporate  such  changes  into  current  and  future  versions  of  the  products. 

Understanding  end  user  requirements  begins  with  the  development  of  the  initial  set  of 
requirements  for  the  acquisition  and  ends  with  the  transfer  of  responsibility  for  the  support  of  the 
acquired  products. 


Goals 


Goal  1  End  user  requirements  are  obtained,  documented,  and  agreed  to  by  the 

end  user. 

Goal  2  End  user  requirements  are  accurately  incorporated  in  the 

requirements  of  the  acquisition. 

Goal  3  Changes  in  end  user  requirements  for  the  acquisition  are  accommodated 

as  appropriate. 

Commitment  to  perform _ 

Commitment  1  The  acquisition  organization  has  a  written  policy  for  conducting 
user  requirement  activities. 

This  policy  typically  specifies  that: 

1.  User  requirements  activities  are  performed  in  accordance  with  the  project’s  defined 
acquisition  process. 


CMU/SEI-2002-TR-010 


L3-9 


User  Requirements  Level  3:  The  Defined  Level 

2.  Appropriate  techniques  are  used  to  elicit  and  analyze  end  user  requirements. 

3.  Risks  associated  with  end  user  requirements  are  identified. 

4.  End  user  requirements  are  incorporated  into  the  requirements  of  the  acquisition. 

5.  End  user  agreement  on  the  requirements  of  the  acquisition  is  obtained. 

6.  The  end  user  is  kept  informed  on  the  status  of  their  requirements  throughout  the  evolution 
of  the  acquisition. 

Commitment  2  Responsibility  for  obtaining  and  documenting  the  end  user’s 
requirements  is  designated. 

Ability  to  perform 

Ability  1  A  group  that  elicits,  develops,  and  maintains  an  understanding  of  the  end 

user’s  requirements  exists. 

Ability  2  Adequate  resources  are  provided  for  eliciting,  developing,  and 

maintaining  an  understanding  of  the  end  user’s  requirements. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Ability  3  Individuals  performing  user  requirements  activities  have  experience  or 

receive  required  training. 

Activities  performed 

Activity  1  The  project  team  performs  its  activities  in  accordance  with  its 

documented  user  requirement  plans. 

Activity  2  The  end  user’s  requirements  and  their  evaluation  criteria  are  elicited. 

Some  examples  of  techniques  to  elicit  end  user  requirements  include: 

interface  control  working  groups, 
technical  control  working  groups, 
interim  project  reviews 
user  operational  scenarios, 
prototypes  and  models, 
brainstorming,  and 
extraction  from  documentation. 
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Activity  3  The  end  user’s  requirements  are  analyzed  and  the  results  documented. 


Some  examples  of  methodologies  used  to  analyze  end  user  requirements  include: 

quality  function  deployment, 
trade  studies, 
mathematical  techniques, 
prototypes,  and 
user  value  determination. 


Activity  4  Agreement  by  the  end  user  that  acquisition  requirements  satisfy  the  end 

user’s  requirements  is  obtained. 


Some  examples  of  forums  to  obtain  user  concurrence  include: 

minutes  from  working  group  meetings,  formal  project  reviews,  focus  groups 
memorandums  of  understanding, 
project  management  plans, 

operational  requirements  documents. _ 


Activity  5  The  end  user’s  requirements  are  provided  as  input  to  the  project’s 

acquisition  requirements  development  and  management  activities. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

Activity  6  The  end  user  is  informed  on  a  regular  basis  about  the  status  and 

disposition  of  their  requirements. 


Some  examples  of  forums  to  inform  the  user  include: 

working  groups, 
formal  project  reviews, 
in-process  reviews, 
status  meetings,  and 

focus  groups.  _ 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  user’s 
requirements  activities. 


Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  towards  completion,  and 
completion  of  milestones. _ 
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Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  user  requirements  process  capability. 


Some  examples  of  measurements  include: 

effort  expended, 
time  expended,  and 
funds  expended. 


Verifying  implementation 


Verification  1  User  requirements  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  user  requirements  activities  at  an  appropriate 
level  of  abstraction.  The  reviews  verify  that  acquisition  organization  policy  is  being 
implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the  organization 
and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are 
available. 


Verification  2  User  requirements  activities  are  reviewed  by  the  project  manager  on  both 
a  periodic  and  event  driven  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to  provide 
awareness  of,  and  insight  into,  understanding  user  needs  and  expectations  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs 
of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. 
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Project  Performance  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Project  Performance  Management  is  to  manage  the  acquisition  project  according 
to  a  defined  acquisition  process. 

Project  Performance  Management  involves  developing  the  project’s  defined  acquisition  process 
and  managing  the  acquisition  using  this  defined  process.  The  project’s  defined  acquisition 
process  is  adapted  from  the  acquisition  organization’s  standard  acquisition  process  to  address 
specific  attributes  of  the  project. 

The  project’s  management  plans  are  based  on  the  project’s  defined  acquisition  process.  These 
plans  describe  how  the  project’s  defined  acquisition  process  will  be  implemented  and  managed. 

The  basic  requirements  for  estimating,  planning,  and  tracking  an  acquisition  project  are 
established  in  the  Acquisition  Planning,  Project  Management,  and  Contract  Tracking  and 
Oversight  key  process  areas.  The  emphasis  in  Project  Performance  Management  at  Level  3  shifts 
from  reacting  to  acquisition  problems  and  issues  to  anticipating  these  problems  and  acting  to 
mitigate  the  risk. 

Goals 


The  project  is  managed  according  to  a  deflned  acquisition  process  which 
was  adapted  from  the  acquisition  organization’s  standard  acquisition 
process. 

The  project  team  achieves  its  acquisition  objectives. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  planning  and 
managing  of  the  project’s  acquisition  activities. 

This  policy  typically  specifies  that: 

1.  The  project’s  defined  acquisition  process  is  developed  and  documented  by  adapting  the 
acquisition  organization’s  standard  acquisition  process  according  to  approved  adaptation 
guidelines. 

Refer  to  Activity  5  of  the  Process  Definition  and  Maintenance  key  process  area. 


Goall 


Goal  2 
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2.  The  project’s  acquisition  activities  are  planned  and  performed  according  to  the  project’s 
defined  acquisition  process. 

3.  Appropriate  project  measurement  data  are  collected  and  stored  by  the  project  team 
according  to  the  acquisition  organization’s  acquisition  process  repository  requirements. 

Ability  to  perforin 


Ability  1  The  individuals  responsible  for  managing  the  acquisition  project 

activities  have  experience  or  receive  required  training. 


lExperience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project  and  having  experience  in  the  domain  of  the  application 
being  acquired.  Additionally,  some  individuals  should  have  experience  in  project 
planning,  organizing,  controlling,  budgeting,  and  scheduling. _ 


Activities  performed 


Activity  1  The  project’s  defined  acquisition  process  is  developed  and  documented 

by  adapting  the  acquisition  organization’s  standard  acquisition  process 
according  to  the  organization’s  adaptation  guidelines. 

Refer  to  Activity  5  of  the  Process  Definition  and  Maintenance  key  process  area. 


Activity  2  The  project  team  develops  and  maintains  the  Project  Management  Plan 

in  accordance  with  the  acquisition  organization’s  standard  acquisition 
process. 

Refer  to  the  Acquisition  Planning,  Project  Management,  and  Contract  Tracking  and 

Oversight  key  process  areas. 

The  Project  Management  Plan  typically  addresses: 

1.  Management  of  solicitation  and  proposal  evaluation  plans. 

2.  Management  of  transition  to  support  plans. 

3.  Provisions  for  gathering,  analyzing,  and  reporting  measurement  data  needed  to  manage 
the  acquisition  project. 

4.  Activities  for  software  estimating,  planning,  and  tracking  related  to  the  key  tasks  and 
work  products  of  the  project’s  defined  acquisition  process. 

5.  Readiness  and  completion  criteria  established,  documented,  and  used  to  authorize 
initiation  and  determine  completion  of  key  tasks. 
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6.  Critical  dependencies  and  paths  that  are  to  be  reflected  in  the  schedule  and  tracked  on  a 
regular  basis. 

7.  Documented  criteria  indicating  when  to  review  and  revise  the  Project  Management  Plan. 

8.  Review  and  use  of  acquisition  management  lessons  learned,  recorded,  and  stored  in  the 
acquisition  organization’s  acquisition  process  repository  to  estimate,  plan,  track,  and  re¬ 
plan  the  acquisition  project. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

9.  A  staffing  plan  that  addresses  the  acquisition  project’s  needs  for  individuals  with  special 
skills  and  acquisition  domain  knowledge. 

10.  Training  needs  identified  and  documented  to  fit  the  specific  needs  of  the  acquisition 
project. 

Refer  to  the  Training  Program  key  process  area. 

11.  Acquisition  management  plans  and  processes  to  be  followed  in  interacting  with  other 
groups. 

12.  Risk  management  planning. 

Refer  to  Activity  2  of  the  Acquisition  Risk  Management  key  process  area. 

13.  Resources  to  accomplish  the  requirements  of  the  Project  Management  Plan. 

14.  Management  of  both  organizational  and  technical  interfaces. 

15.  Adaptation  of  the  acquisition  organization’s  standard  acquisition  process. 

Activity  3  The  project  team’s  acquisition  management  activities  are  performed  in 

accordance  with  the  project’s  defined  acquisition  process  and  the  Project 
Management  Plan. 

Activity  4  The  project’s  defined  acquisition  process  is  revised  as  required  to  remain 

consistent  with  current  project  objectives. 

Activity  5  The  project  team  coordinates  its  activities  with  other  organizations  and 

activities  supporting  the  project. 

Activity  6  The  acquisition  organization’s  acquisition  process  repository  is  used  for 

project  planning,  estimating,  and  management. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Activity  7  Critical  dependencies  between  groups  involved  in  the  acquisition  are 

identified,  negotiated,  and  managed. 
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Activity  8  The  project  team  performs  periodic  reviews  to  ensure  current  and 

projected  needs  of  the  end  user  will  be  satisfied. 

Activity  9  Measurements  are  used  to  determine  project  team  performance  and 

trends  analyzed. 

Examples  of  measurements  include: 

effort  expended  over  time, 
frequency  of  replanning, 

number  and  magnitude  of  adverse  impacts  on  the  project, 
number  of  requirements  changes,  and 
number  of  contract  changes. _ 

Trend  analysis  relies  on  internal  and  external  data. 


Activity  10 


Activity  11 


The  project  team  identifies  and  analyzes  risks  and  identifies  specific  risk 
mitigation  actions  for  those  risks. 

Refer  to  Activity  3  of  Software  Acquisition  Planning,  Activity  7  of  Contract  Performance 
Management,  and  Activity  5  of  Acquisition  Risk  Management  key  process  areas. 

The  project  team’s  acquisition  process  assets,  acquisition  results,  and 
lessons  learned  are  identified,  documented,  and  entered  into  the 
acquisition  organization’s  acquisition  process  repository. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  project 
performance  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. 

Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  project  performance  management  process  capability. 
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Verification  1 


Verification  2 


Some  examples  of  measurements  include: 

effort  expended, 
time  expended,  and 
funds  expended. 


Verifying  implementation 


Project  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  performance  management  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Project  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


The  review  should  include  the  activities  performed  as  specified  in  the  Project 
Management  Plan. _ 


CMU/SEI-2002-TR-010 


L3-17 


Contract  Performance  Management 


Level  3;  The  Defined  Level 


Contract  Performance  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  products  that  satisfy  contract 
requirements. 

Contract  Performance  Management  involves  appraising  the  supplier  team’s  engineering 
performance  and  the  quality  of  the  evolving  products.  Based  on  the  results  of  the  appraisals,  the 
acquisition  may  be  adjusted.  The  process  includes  evaluation  of  final  products  to  determine 
satisfaction  of  contractual  requirements.  The  emphasis  in  contract  performance  management  is 
to  be  proactive  regarding  supplier  team  performance  and  contract  compliance  issues  and  to 
minimize  the  effects  of  these  issues.  Additional  activities  include  contributing  to  the  project’s 
risk  management  activities,  fostering  an  environment  of  mutual  cooperation  with  the  supplier, 
and  identifying  improvements  to  the  contract  performance  management  process. 

The  contract  performance  management  process  integrates  contract  performance  management 
activities  with  other  project  management  activities.  Contract  Performance  Management  builds 
on  the  Contract  Tracking  and  Oversight  and  Evaluation  key  process  areas.  Contract  performance 
management  begins  when  the  contract  is  awarded  and  ends  at  the  conclusion  of  the  contract's 
period  of  performance. 


Goals 


Goal  1  The  quality  of  supplier  team  process,  performance,  and  products  is 

appraised  throughout  the  contract's  period  of  performance  to  identify 
risks  and  take  action  to  mitigate  those  risks  as  early  as  possible. 

Goal  2  Contract  Performance  Management  activities  intended  to  foster  a 

cooperative  and  productive  environment  among  the  end  user,  project 
team,  and  the  supplier  team  are  implemented. 


Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  M'ritten  policy  for  the  performance  of 
contract  performance  management  activities. 
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This  policy  typically  specifies  that: 

1.  Contract  performance  management  activities  are  performed  in  accordance  with  the 
project’s  defined  acquisition  process. 

2.  Appropriate  tools  and  methodologies  are  used  to  evaluate  the  products. 

3.  Risk  analysis  and  management  are  included  as  part  of  the  contract  performance 
management  activities. 

4.  Products  must  pass  a  successful  evaluation  of  contract  requirements  before  they  are 
accepted. 

5.  Product  acceptance  is  dependent  on  the  successful  completion  of  operational  evaluation. 

6.  Evaluation  requirements  and  measurable  acceptance  criteria  are  established  before  the 
request  for  proposals  is  released. 

7.  The  supplier  is  encouraged  to  establish  a  rigorous  engineering  evaluation  process. 

8.  The  project’s  evaluation  planning  is  updated  to  reflect  changes  to  the  requirements. 

Ability  to  perform 


Ability  1  Individuals  performing  contract  performance  management  activities  have 

experience  or  receive  required  training  in  related  acquisition  disciplines 
and  contract  performance  management  procedures. 


Experience  means,  for  example,  having  participated  on  more  than  one  development 
project  including  appraising  the  supplier's  planning  documents,  engineering  process, 
products,  and  services;  having  knowledge  of  current  development  technologies;  and 
having  knowledge  in  the  domain  of  the  application  being  acquired. _ 


jTraining  includes  areas  of  evaluation,  data  reduction,  and  analysis  techniques. 


Activities  performed 


Activity  1  The  project  team  performs  its  activities  in  accordance  with  its 

documented  contract  performance  management  plans. 

In  addition  to  the  planning  information  called  for  in  the  Contract  Tracking  and  Oversight  key 
process  area,  these  plans  also  typically  cover: 

1.  The  guidelines  and  criteria  used  in  defining  the  project’s  contract  performance 
management  activities. 

2.  The  activities  to  be  performed  and  the  schedule  to  perform  the  activities. 


CMU/SEI-2002-TR-010  L3-19 


Contract  Performance  Management 


Level  3:  The  Defined  Level 


3.  Risk  management. 

Refer  to  Activity  3  of  Acquisition  Planning  and  Activity  I  of  the  Contract  Tracking  and 
Oversight  key  process  areas. 


Activity  2  The  supplier  team’s  engineering  process  is  appraised  periodically  and 

trends  analyzed. 

Typical  activities  include: 

1.  The  supplier  team’s  engineering  process,  practices,  methodologies,  and  procedures  are 
continually  appraised  for  effectiveness  and  for  compliance  with  contractual  requirements. 

2.  The  supplier’s  quality  assurance,  configuration  management,  corrective  action,  and  risk 
management  systems  and  processes  are  appraised  for  compliance  with  standards  and 
plans  to  ensure  that  associated  results  support/promote  attainment  of  contract  objectives 
and  compliance  with  contractual  requirements. 

3.  Trend  analysis  of  the  supplier  team’s  engineering  process  is  performed  to  detect  issues  in 
satisfying  contractual  requirements  as  early  as  possible. 

Activity  3  Results  of  the  supplier  team’s  engineering  activities  are  appraised 

periodically  and  trends  analyzed. 

Appraisals  conducted  typically  verify  that: 

1.  The  requirements  are  being  developed,  documented,  maintained,  and  verified  according 
to  the  supplier  team’s  engineering  process  and  are  traceable  to  higher  level  requirements. 

2.  The  product  architecture  is  feasible  and  will  satisfy  future  system  growth  and  reuse  needs. 

3.  The  product  design  is  developed,  documented,  maintained,  and  verified  according  to  the 
supplier’s  engineering  process. 

4.  The  product  is  developed  and  documented  according  to  the  supplier’s  engineering 
process. 

5.  The  documentation  that  will  be  used  to  operate  and  support  the  products  is  developed  and 
maintained  according  to  the  supplier’s  engineering  process. 

6.  The  integration  of  commercial  off-the-shelf  (COTS)  products  with  developed  software  is 
accomplished  in  accordance  with  the  supplier’s  engineering  process  and  planning 
documents. 

Activity  4  Results  from  the  process  and  product  trend  analyses  are  used  to  evaluate 

the  supplier  team’s  performance. 


Trend  analysis  can  rely  on  internal  and  external  data. 
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Activity  5 


Activity  6 


Activity  7 


As  the  project  team^s  understanding  of  the  supplier  team’s  engineering 
process  and  products  improves,  the  project  team  may  propose  changes  to 
their  acquisition  process. 

L  The  project  team  determines  the  impact  of  changes  before  the  changes  are  implemented. 

2.  Changes  to  the  acquisition  approach  are  coordinated  within  the  project  team  and 
communicated  to  other  affected  groups. 

3.  Adjustments  that  affect  contractual  requirements  are  made  through  official  contracting 
channels. 

The  end  user  periodically  participates  in  the  evaluation  of  evolving 
products  to  determine  the  satisfaction  of  operational  requirements. 

Refer  to  Activity  5  of  the  Evaluation  key  process  area. 

Contract  performance  management  activities  are  performed  to  foster  a 
cooperative  and  productive  environment  among  the  end  user,  project 
team,  and  the  supplier  team. 

Typical  activities  include: 

1 .  Supporting  a  mutual  understanding  of  the  contract’s  requirements  (and  their  flow  down) 
between  the  project  team  and  the  supplier  team. 

2.  Maintaining  ongoing  communications  between  the  project  team  and  the  supplier  team  at 
appropriate  levels. 

3.  Allowing  the  supplier  to  manage  the  engineering  efforts  for  which  it  is  responsible, 
including  engineering  evaluation,  with  minimal  project  team  interference. 

4.  Promoting  the  joint  development  of  solutions  to  issues  by  the  project  team  and  the 
supplier  team. 

5.  Requiring  that  the  project  team  satisfy  its  commitments  to  the  supplier  team,  such  as 
review  of  supplier-generated  documentation  and  timely  feedback  of  the  results  of  project 
team  evaluations  of  supplier  team’s  performance,  products,  and  services, 

6.  Maintaining  mutual  understanding  of  methods  to  administer  the  contract. 


Some  examples  of  areas  to  be  addressed  include: 

maintenance  of  bi-directional,  non-intmsive  communications  between  the  project  team  and  the 
supplier  team; 

how  issues  and  concerns  not  resolvable  at  lower  levels  will  be  decided; 
methods  of  identifying  and  mitigating  risks;  and 

the  use  of  both  process  and  product  measurements  as  a  common  basis  of  communication  to  understand 
the  requirements  and  the  status  of  the  project. _ _ _ 
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Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
performance  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 

understand  the  contract  performance  management  process  capability. 


Some  examples  of  measurements  include: 
effort  expended, 
time  expended,  and 
funds  expended. _ 


Verifying  implementation 


Verification  1  Contract  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  performance  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Verification  2 


Contract  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Acquisition  Risk  Management _ 

a  key  process  area  for  Level  3:  Defined _ _ 

The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible,  adjust  the 
acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk  management 
process  as  an  integral  part  of  the  acquisition  organization’s  standard  acquisition  process. 
Acquisition  risk  management  begins  with  the  process  of  defining  the  acquisition  need  and 
terminates  when  the  acquisition  is  completed.  Acquisition  risk  management  becomes  an  integral 
part  of  the  solicitation,  project  performance  management,  and  contract  performance  management 
processes. 

Acquisition  risk  management  is  a  two-part  process.  First,  the  acquisition  strategy  identifies  the 
risks  associated  with  the  acquisition  and  the  approach  is  planned  based  on  those  risks.  Second,  a 
process  is  employed  to  manage  the  risks  throughout  the  acquisition. 

Risk  identification  includes  categorization  of  the  risk  based  on  historical  data  and  estimates  to 
determine  the  impact  of  each  risk  on  quality,  performance,  schedule,  and  cost.  The  risks  are 
analyzed  to  determine  their  impact  on  acquisition  strategy  and  engineering.  Analysis  includes 
determining  the  driver  of  each  risk  area  and  the  impact  of  the  risk  so  that  risk-handling  strategies 
may  be  proposed  and  tested. 

Acquisition  risk  management  is  planned  through  the  Acquisition  Risk  Management  Plan  that 
details  the  processes  to  take  place  in  acquisition  planning  and  acquisition  management.  The 
Acquisition  Risk  Management  Plan  describes  the  management  actions  and  procedures  to 
identify,  analyze,  and  rank  order  risks,  and  the  risk  handling  methods  to  be  applied. 

Goals 


Goal  1  Project-wide  participation  in  the  identiflcation  and  mitigation  of  risks  is 

encouraged. 

Goal  2  The  project  team’s  deHned  acquisition  process  provides  for  the 

identiflcation,  analysis,  and  mitigation  of  risks  for  all  project  functions. 

Goat  3  Project  reviews  include  the  status  of  identifled  risks. 
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Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  management  of 
acquisition  risk. 

This  policy  typically  specifies  that: 

1.  Risk  identification  is  performed  throughout  the  project  life  cycle  in  accordance  with  the 
project’s  defined  acquisition  process. 

2.  Risk  management  activities  involve  the  project  team,  end  user,  and  the  supplier  team  as 
appropriate. 

3.  Risk  management  is  a  positive  and  proactive  part  of  acquisition. 

4.  Risk  information  is  communicated  throughout  the  project  team. 

Commitment  2  Responsibility  for  acquisition  risk  management  activities  is  designated. 

Ability  to  perform 


Ability  1  A  group  that  performs  the  coordination  of  acquisition  risk  management 

activities  exists. 

Ability  2  Adequate  resources  are  provided  for  acquisition  risk  management 

activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Ability  3  Individuals  performing  acquisition  risk  management  activities  have 

experience  or  receive  required  training. 

Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  and  having  applied  risk  management  techniques  on  at  least  one  project  and 
having  experience  in  the  domain  of  the  application  being  acquired. _ 

Activities  performed 


Activity  1  Acquisition  risk  management  activities  are  integrated  into  acquisition 

planning. 

Risk  management  includes  risk  identification,  analysis,  planning,  tracking,  and 
controlling. _ 
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The  acquisition  strategy  evolves  based  on  risk  identification  and 
analysis. _ 


Refer  to  Activity  3  of  the  Acquisition  Planning  key  process  area. 

Activity  2  The  Acquisition  Risk  Management  Plan  is  developed  in  accordance  with 

the  project’s  defined  acquisition  process. 

The  Acquisition  Risk  Management  Plan  typically  addresses: 

1.  The  processes  and  associated  plans  for  identifying,  analyzing,  mitigation,  tracking  and 
controlling  risks,  and  summary  of  methods  and  tools  to  be  used. 

2.  Assumptions,  constraints,  and  policies  governing  the  projects  risk  management  activities. 
3-  Communication  framework  for  managing  the  risk  processes,  including: 

4.  Identification  of  critical  dependencies  and  paths  that  are  to  be  reflected  in  the  schedule 
and  tracked  on  a  regular  basis. 

5.  Procedures  to  be  followed  in  interacting  with  other  groups. 

6.  Mechanisms  for  reporting  risk  management  activities. 

7.  The  process  for  managing  and  controlling  the  Acquisition  Risk  Management  Plan,  with 
documented  criteria  indicating  when  to  review  and  revise  the  plan. 

8.  Review  and  use  of  risk  management  lessons  learned,  recorded,  and  stored  in  the 
acquisition  organization’s  acquisition  process  repository  to  estimate,  plan,  track,  and  re¬ 
plan  the  risk  management  activities. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

9.  A  staffing  plan  that  addresses  the  acquisition  project’s  needs  for  individuals  with  special 
skills  for  risk  activities. 

10.  Resources  and  budgets  to  accomplish  the  requirements  of  the  Acquisition  Risk 
Management  Plan. 

11.  Training  needs  identified  and  documented  to  fit  the  specific  needs  of  the  acquisition 
project  for  risks. 

Refer  to  the  Training  Program  key  process  area. 

12.  Provisions  for  gathering,  analyzing,  and  reporting  measurement  data  needed  to  manage 
the  acquisition  risk  activities. 

Refer  to  Activity  4  of  the  Acquisition  Planning  key  process  area. 
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Activity  3 


The  project  team  performs  its  acquisition  risk  management  activities  in 
accordance  with  its  documented  plans. 


Activity  4 


Activity  5 


Activity  6 


Activity  7 


The  project  team  encourages  project-wide  participation  in  the 
identification  and  mitigation  of  risks. 

1.  Mitigation  plans  and  decisions  are  predicated  upon  key  project  milestones. 

2.  Risks  are  presented,  discussed,  and  action  taken  in  a  non-threatening  environment. 

3.  Where  appropriate,  research  on  individual  risks  is  authorized  and  encouraged. 

Risk  management  is  conducted  as  an  integral  part  of  the  solicitation,  user 
requirements,  project  performance  management,  and  contract 
performance  management  processes. 

Refer  to  Activity  1  of  Solicitation,  Activities  2  and  10  of  Project  Performance  Management, 
and  Activities  1  and  2  of  the  Contract  Performance  Management  key  process  areas. 

Acquisition  risks  are  analyzed,  tracked,  and  resolved  or  controlled  until 
mitigated. 

These  actions  typically  include: 

1 .  Tracking  the  status  of  the  risks  and  planned  mitigations. 

2.  Reporting  of  the  updated  risk  assessments. 

3.  Planned  mitigation  actions  are  maintained  current. 

Project  reviews  include  the  status  of  identified  risks. 

Items  reported  typically  include; 

1 .  Changes  in  the  priority  of  risks. 

2.  Changes  in  mitigation  plans. 

3.  New  risks  identified. 

Refer  to  Activity  10  of  the  Project  Performance  Management  key  process  area. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 
acquisition  risk  management  activities  and  resultant  products. 
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Some  examples  of  measurements  include: 
compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. _ 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  acquisition  risk  management  process  capability. 


Some  examples  of  measurements  include: 
effort  expended, 
time  expended,  and 
funds  expended. _ 


Verifying  implementation 


Verification  1  Acquisition  risk  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  risk  management  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ _ 

Verification  2  Acquisition  risk  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


Each  review  should  include  the  activities  performed  as  specified  in  the  Acquisition 
Risk  Management  Plan. _ _ 
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Training  Program  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Training  Program  Management  is  to  ensure  the  development  of  the  skills  and 
knowledge  of  individuals  so  they  can  perform  their  acquisition  roles  effectively  and  efficiently. 

Training  Program  Management  involves  appraisal  of  training  requirements  at  the  acquisition 
organization,  project,  and  individual  levels.  Training  program  management  surveys  the  current 
and  future  skill  needs  and  determines  how  these  skills  will  be  obtained.  Current  weaknesses 
throughout  the  acquisition  organization  are  understood  and  plans  are  developed  to  systematically 
address  the  weaknesses. 

Some  skills  are  effectively  and  efficiently  imparted  through  informal  vehicles,  whereas  other 
skills  need  more  formal  training  vehicles  to  be  effectively  and  efficiently  imparted.  The 
appropriate  vehicles  are  selected  and  used. 

Members  of  the  acquisition  organization  are  schooled  in  the  standard  acquisition  process,  the 
project,  the  domain  of  the  products  to  be  acquired,  and  in  the  skills  and  knowledge  needed  to 
perform  their  jobs  effectively.  Members  effectively  use,  or  are  prepared  to  use,  the  capabilities 
and  features  of  the  existing  and  planned  work  environment.  The  project  teams  become  more 
effective  through  a  better  understanding  of  their  work  processes. 

This  key  process  area  covers  the  group  that  has  oversight  of  the  training  function.  The  processes 
identifying  specific  training  topics  (e.g.,  knowledge  or  skills  needed)  are  contained  in  the 
common  feature  “Ability  to  perform”  of  the  individual  key  process  areas. 

Goals 


Training  required  for  the  projects  to  achieve  their  acquisition  objectives 
is  identiHed  and  provided. 

The  training  program  satisfies  the  acquisition  organization’s  training 
needs,  including  training  on  the  standard  acquisition  process. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  satisfying  its 
training  needs. 


Goall 

Goal  2 
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Commitment  2 


Ability  1 


Ability  2 


This  policy  typically  specifies  that: 

1.  The  needed  skills,  knowledge,  and  abilities  are  identified  for  each  acquisition  managerial 
and  technical  role  within  this  model. 

2.  The  training  program  is  developed  to  build  the  skill  base  of  the  acquisition  organization, 
to  fill  the  specific  needs  of  the  acquisition  projects,  and  to  develop  the  skills  of 
individuals. 

3.  Training  is  provided  from  within  the  acquisition  organization  or  obtained  from  outside  the 
acquisition  organization  when  appropriate. 

Some  examples  of  external  training  sources  include: 

end  user-provided  training, 

commercially  available  training  courses, 

academic  programs, 

professional  conferences,  and 

seminars.  _ _ 


4.  Training  vehicles  for  imparting  skills  and  knowledge  are  identified,  approved,  and 
managed. 

Some  examples  of  training  vehicles  include: 

classroom  training, 
computer-aided  instruction, 
guided  self-study, 

formal  apprenticeship  and  mentoring  programs,  and 
facilitated  videos.  _ 


Responsibility  for  implementing  the  acquisition  organization’s  training 
program  is  designated. 

Ability  to  perform 


A  group  that  fulfllls  the  training  needs  of  the  acquisition  organization 
exists. 


The  members  of  the  training  group  may  include  full-time  or  part-time  instructors 
drawn  from  the  organization  and  from  external  sources. _ 


Adequate  resources  are  provided  for  training  program  management 
activities. 

1.  Resources  include  funding,  staff,  equipment,  and  tools. 

2.  Appropriate  facilities  are  made  available  to  conduct  training. 

►  Classroom  training  facilities  should  be  separated  from  the  students'  work 
environments  to  minimize  interruptions. 
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►  Where  appropriate,  training  is  conducted  in  settings  that  closely  resemble  actual 
performance  conditions  and  includes  activities  to  simulate  actual  work  situations. 

Ability  3  Members  of  the  training  group  have  the  necessary  skills  and  knowledge 

to  perform  their  training  activities. 


Some  examples  of  ways  to  provide  these  skills  and  knowledge  include: 
training  in  instructional  techniques  and 
refresher  training  in  the  subject  matter. 


Ability  4  Acquisition  management  personnel  receive  orientation  on  the  training 

program. 


Some  examples  of  topics  for  orientation  include: 
corporate  training  program  objectives  and  plan, 
process  for  determination  of  training  needs, 
methods  for  providing  required  training,  and 
identification  of  training  sources. 


Activities  performed 


Activity  1  The  acquisition  organization’s  training  program  is  planned,  developed, 

implemented,  and  maintained  to  support  the  organization’s  training 
requirements. 


Some  examples  of  training  program  elements  include: 
the  acquisition  organization’s  training  plan, 
training  materials, 

development  or  procurement  of  training, 
conduct  of  training, 
training  facilities, 
appraisal  of  training,  and 
maintaining  training  records. 


The  acquisition  organization’s  training  program  typically  covers: 

1.  Training  senior  management  in  the  technologies  and  strategies  that  are  being  used  for 
acquisition  management. 

2.  The  set  of  skills  needed  and  when  those  skills  are  needed. 

3.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 

Training  for  individuals  is  tied  to  their  work  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 

4.  Developing  individual  training  plans. 
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5.  How  training  will  be  provided. 

The  training  may  be  provided  by  the  project,  by  the  acquisition  organization’s  training  program,  or  by 
an  external  group. _ _ _  _ _ 


Activity  2 


Activity  3 


Activity  4 


Activity  5 


Each  acquisition  project  identifies  specific  training  needs  and  develops  a 
training  plan  in  accordance  with  training  program  procedures. 

The  project’s  training  plan  typically  covers: 

1.  The  set  of  skills  needed  and  when  those  skills  are  needed. 

2.  Skills  for  which  training  is  required  and  the  skills  that  will  be  obtained  via  other  vehicles. 

3.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 

Training  for  individuals  is  tied  to  their  work  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 

4.  How  training  will  be  provided  with  a  breakdown  of  resources  required  to  provide  this 
training. 

The  training  may  be  provided  by  the  project,  by  the  organization’s  training  program,  or  by  an  external 
group. _ _ _ _ _ 

5.  The  requirement  that  the  acquisition  project’s  training  plans  undergo  a  peer  review. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

Acquisition  training  for  the  acquisition  organization  is  provided  in 
accordance  with  the  organization’s  training  program. 

A  waiver  procedure  for  required  training  is  established  and  used  to 
determine  whether  individuals  already  possess  the  knowledge  and  skills 
required  to  perform  their  designated  acquisition  roles. 

Training  records  are  maintained. 

Some  of  the  records  to  be  maintained  are; 

1.  All  students  who  successfully  complete  each  training  course  or  other  approved  training 
activity. 

2.  All  students  who  successfully  complete  their  designated  required  training  as  specified  in 
their  training  plan. 

3.  Successfully  completed  training. 


Activity  6  Measurements  are  used  to  determine  the  quality  of  the  training  program. 
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Some  examples  of  measurements  include: 

reviews  of  the  courses  from  the  students, 
reviews  of  the  class  from  the  instructor,  and 
feedback  from  the  managers. _ 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  training 
program  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  training  program  management  process  capability. 


Some  examples  of  measurements  include: 
effort  expended, 
time  expended,  and 
funds  expended. 


Verifying  implementation 


Verification  1 


Training  program  management  activities  are  reviewed  by  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  organization  management  is  to  provide 
awareness  of,  and  insight  into,  training  program  activities  at  an  appropriate  level  of 
abstraction.  The  reviews  verify  that  organization  policy  is  being  implemented.  The 
time  between  reviews  should  satisfy  the  needs  of  the  organization  and  may  be 
lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are  available. 
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At  the  Quantitative  Level,  the  project  team  sets  quantitative  quality  objectives  for  processes  and 
products.  A  process  is  established  to  provide  a  quantitative  foundation  for  evaluating  project 
processes  and  products. 

Project  teams  achieve  control  over  acquisition  processes  and  products  by  narrowing  the  variation 
in  project  performance  to  within  acceptable  quantitative  boundaries.  Data  on  the  defined 
acquisition  process  and  variations  outside  the  acceptable  quantitative  boundaries  are  used  to 
adjust  the  process  to  prevent  recurrence  of  deficiencies.  An  acquisition  organization-wide 
process  repository  provides  for  the  collection  and  analysis  of  data  from  the  projects’  defined 
acquisition  processes. 

The  process  capability  of  Level  4  acquisition  organizations  can  be  summarized  as  measured  and 
operating  within  measurable  limits.  This  level  of  process  capability  allows  an  organization  to 
predict  process  and  product  quality  trends  within  the  quantitative  bounds  of  these  limits.  When 
these  limits  are  exceeded,  action  is  taken  to  correct  the  situation. 

Level  4  key  process  areas  are; 

Quantitative  Process  Management 
Quantitative  Acquisition  Management 
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Quantitative  Process  Management 

a  key  process  area  for  Level  4:  Quantitative 


The  purpose  of  Quantitative  Process  Management  is  to  quantitatively  control  the  project’s 
performance  resulting  from  implementation  of  the  acquisition  process.  Projects  fully 
implementing  quantitative  process  management  will  have  stable  processes  that  are  under 
quantitative  control.  Additionally,  the  capability  of  the  acquisition  organization’s  standard 
acquisition  process  is  defined  quantitatively. 

Quantitative  Process  Management  involves  each  project  team  setting  performance  objectives, 
measuring  performance,  analyzing  results,  and  making  adjustments  to  maintain  performance 
within  acceptable  limits.  Performance  variations  (i.e.,  variations  attributable  to  specific 
implementations  of  the  process)  are  measured  and  actions  taken  to  bring  performance  within 
acceptable  limits.  When  the  project  team’s  performance  is  stabilized  within  acceptable  limits, 
the  defined  acquisition  process,  the  associated  measurements,  and  the  acceptable  performance 
limits  are  baselined  to  permit  quantitative  control  of  the  project  team’s  performance. 

The  acquisition  organization  collects  performance  data  from  the  acquisition  projects  and  uses 
these  data  to  define  the  capability  of  its  standard  acquisition  process  (see  the  Process  Definition 
and  Maintenance  key  process  area).  The  capability  of  the  acquisition  organization’s  standard 
acquisition  process  is  indicative  of  the  performance  that  can  be  expected  from  the  next 
acquisition  project  undertaken.  These  capability  data  are,  in  turn,  used  by  the  acquisition  project 
teams  to  set  their  performance  objectives  and  to  analyze  the  performance  of  their  defined 
acquisition  processes.  The  capability  data  are  also  used  by  the  project  teams  in  adapting  the 
acquisition  organization’s  standard  acquisition  process  to  a  particular  acquisition. 


Goals 


Goal  1  The  performance  of  each  project  is  quantitatively  measured,  managed, 

and  controlled. 

Goal  2  The  capability  of  the  acquisition  organization’s  standard  acquisition 

process  is  analyzed  and  deflned  in  quantitative  terms. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  measurement 
and  quantitative  control  of  acquisition  process  performance. 
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Commitment  2 


Ability  1 


The  term  “quantitative  control”  implies  any  quantitative  or  statistically  based 
technique  appropriate  for  analyzing  an  acquisition  process,  identifying  causes  of 
process  performance  variations,  and  adjusting  the  process  to  bring  performance 
within  prescribed  limits. _ 


This  policy  typically  specifies  that: 

1.  Each  project  team  plans  and  implements  quantitative  control  of  its  defined  acquisition 
process. 

2.  Access  to  sensitive  data  is  appropriately  controlled. 

The  acquisition  organization  has  a  written  policy  for  analysis  of  the 
capability  of  its  standard  acquisition  process. 

This  policy  typically  specifies  that: 

1 .  Each  project  team’s  measurements  of  process  performance  are  analyzed  to  establish  and 
maintain  a  process  capability  baseline  for  the  acquisition  organization’s  standard 
acquisition  process. 

►  The  process  capability  baseline  includes: 

*  The  description  of  the  acquisition  organization’s  standard  acquisition  process. 

*  The  standard  definitions  of  the  measurements. 

*  The  expected  range  of  values  for  the  measurements. 

2.  The  acquisition  organization’s  acquisition  process  capability  baseline  is  used  by  each 
project  team  in  establishing  its  process  performance  objectives. 

Ability  to  perform 


Adequate  resources  are  provided  for  quantitative  process  management 
activities. 

Resources  include  funds,  staff,  equipment,  and  tools. 

►  Tools  to  support  quantitative  process  management  activities  are  made  available. 
Some  examples  of  quantitative  process  management  tools  include: 

project  management  systems, 
cost  and  schedule  control  systems, 
requirements  management  systems, 
database  systems, 
quantitative  analysis  packages,  and 

deficiency  tracking  packages. _ 
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Ability  2 
Ability  3 


Ability  4 

Activity  1 


Acquisition  organization  management  support  exists  for  collecting, 
recording,  storing,  and  analyzing  process  and  product  measurement  data. 

The  individuals  implementing  or  supporting  quantitative  process 
management  activities  have  experience  or  receive  required  training. 


Experience  means,  for  example,  having  participated  in  an  acquisition  management 
role  on  at  least  one  project  and  having  a  minimum  of  three  years  experience  in 
acquisition,  measurement,  and  statistical  process  control. _ 


Some  examples  of  experience  or  training  include: 

defining  and  performing  the  acquisition  process; 
modeling  and  analyzing  the  acquisition  process; 
selecting,  collecting,  and  verifying  process  measurement 
data; 

applying  basic  quantitative  methods  and  analysis  techniques; 
and 

defining  quantitative  objectives  for  process  management. 


The  members  of  the  project  team  and  groups  supporting  the  acquisition 
project  receive  orientation  on  the  objectives  and  values  of  quantitative 
process  management. 

Activities  performed 


The  acquisition  organization’s  acquisition  process  capability  baseline  is 
deflned  in  quantitative  terms  and  is  maintained  according  to  a  written 
procedure. 

This  procedure  typically  specifies  that: 

1.  Project  teams’  process  performance  is  analyzed  to  establish  the  acquisition  organization’s 
quantitative  process  capability  baseline. 

2.  Process  capability  trends  for  the  acquisition  organization’s  standard  acquisition  process 
are  examined  to  predict  likely  deficiencies  or  opportunities  for  improvements. 
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Some  examples  of  using  measured  capability  trends  include: 

predicting  the  occurrence  of  project  deficiencies  and  comparing  the  predictions  to  actuals  and 
predicting  the  distribution  and  severity  of  deficiencies  remaining  in  a  project  team  work  product 
based  on  data  from  reviews. 


3.  Changes  to  the  acquisition  organization’s  standard  acquisition  process  are  tracked  and 
analyzed  to  determine  their  effect  on  the  quantitative  process  capability  baseline. 

Activity  2  Each  project  team’s  quantitative  goals  and  objectives  are  derived  from 

the  acquisition  organization’s  quantitative  process  capability  baseline. 

Activity  3  Each  project  team  performs  its  activities  in  accordance  with  its 

documented  quantitative  process  management  plans. 

The  plans  typically  cover: 

L  The  goals  and  objectives  of  the  project  team’s  quantitative  process  management  activities. 
2.  The  acquisition  tasks  or  other  acquisition  tasks  that  will  be  measured  and  analyzed. 


The  data  collection  and  the  quantitative  analyses  strategy  are  based  on  the  project’s  defined  acquisition 
process. _ _ _ 

3.  The  instrumentation  of  the  project’s  defined  acquisition  process. 


The  instrumentation  is  based  on  the  acquisition  organization’s  measurement  program,  the  description 
of  the  acquisition  organization’s  standard  acquisition  process,  and  the  description  of  the  project’s 
defined  acquisition  process. _ _ _ 

4.  The  quantitative  process  management  activities  to  be  performed  and  the  schedule  for 
these  activities. 


In  addition  to  current  organizational  and  project  needs,  measurements  that  may  be  useful  to  future 
efforts  may  be  included. _ 

5.  The  groups  and  individuals  responsible  for  the  quantitative  process  management 
activities. 

6.  The  resources  required  to  perform  the  quantitative  process  management  activities, 
including  staff  and  tools. 

7.  The  procedures  to  be  followed  in  performing  the  quantitative  process  management 
activities. 

Activity  4  The  measurement  data  used  to  quantitatively  control  the  project’s 

deUned  acquisition  process  are  collected  and  analyzed  in  accordance  with 
the  acquisition  organization’s  standard  acquisition  process. 


Some  examples  of  measurement  data  include: 
effort,  schedule,  and  cost  estimates  used  in  the  solicitation  phase; 
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actual  project  data  on  software  size,  effort,  schedule,  and  cost; 

project  team  productivity  data  (e.g.,  staff  hours  expended,  document  pages 

reviewed,  and  requirements  normally  tested); 

project  team  quality  measurements  (e.g.,  number  and  severity  of  deficiencies 
found  in  the  project  requirements  and  project  team  work  products);  and 
timeliness  of  project  team  work  products. _ 


Project  team  work  products  are  those  products  that  are  produced  by  the  project  team  as  it  executes  the 
project’s  defined  acquisition  process  (e.g.,  solicitation,  acquisition  plans,  document  reviews).  Project 
team  work  products  arc  not  the  deliverables,  products,  end  items,  or  other  output  produced  by  the 
supplier  in  satisfaction  of  the  contract. _ 


The  process  typically  specifies  that: 

1.  The  measurement  data  collected  support  the  acquisition  organization’s  and  the  project 
team’s  measurement  objectives. 

2.  The  specific  measurement  data  to  be  collected,  their  precise  definitions,  the  intended  use 
and  analysis  of  each  measurement,  and  the  process  control  points  at  which  they  are 
collected  are  defined. 

3.  The  measurements  cover  the  properties  of  the  acquisition  process  activities  and  major 
acquisition  work  products. 

4.  The  verification  of  each  project’s  measurement  data  is  independently  determined. 

5.  The  collected  measurement  data  are  stored  in  the  acquisition  organization’s  acquisition 
process  repository  as  appropriate. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Activity  5  Data  from  each  project's  defined  acquisition  process  is  collected, 

analyzed,  and  quantitatively  controlled  according  to  the  project’s 
quantitative  process  management  plans. 

The 

1. 


2.  Measurement  data  on  the  process  activities  throughout  the  project’s  defined  acquisition 
process  are  identified,  collected,  and  analyzed. 

3.  The  acceptable  limits  for  each  measurement  are  defined. 


plans  typically  specify  that: 


Specific  data  analysis  activities  are  predefined. 


[Some  examples  of  items  analyzed  include: 

input  data  required, 
tools  used, 

data  manipulations  performed, 
information  to  be  derived, 

decision  criteria  used  in  performing  the  analysis,  and 

criteria  for  deciding  what  actions  to  take  as  a  result  of  the  analysis. 


An  example  of  establishing  acceptable  limits  is  to  calculate  the  historical  standard  deviation  from  the 
mean  performance  of  the  process. _ 
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4.  The  actual  values  of  each  measurement  are  compared  to  the  acceptable  limits. 

5.  Adjustments  are  made  to  bring  process  performance  in  line  with  the  established 
acceptable  limits. 

6.  Each  project  team’s  acquisition  process  performance  is  established  for  the; 

►  Definition  of  the  measurements. 

►  Actual  measurement  data. 

►  Acceptable  limits  for  the  measurements. 

7.  The  process  performance  for  the  acquisition  project  team  is  managed  and  controlled. 


Activity  6 

Activity  7 
Activity  8 


Causal  analysis  is  conducted  on  an  event  driven  and  periodic  basis  to 
determine  special  causes  of  variances  from  the  project’s  defined 
acquisition  quantitative  process  goals  and  objectives. 


I  An  example  of  a  method  to  determine  special  causes  is  cause/effect  analysis. 


Changes  in  the  project’s  defined  acquisition  process  are  implemented  to 
correct  special  causes  of  variance. 


Reports  documenting  the  results  of  the  project  team’s  quantitative 
process  management  activities  are  prepared  and  recorded  in  the 
acquisition  organization’s  process  repository. 


Refer  to  the  Process  Definition  and  Maintenance  key  process  area  for  incorporating  process 
data  in  the  repository. 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

quantitative  process  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 

completion  of  milestones. _ 

Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  quantitative  process  management  process  capability. 


Quantitative  Process  Management  Level  4;  The  Quantitative  Level 


time  expended,  and 
funds  expended. 


Measurement  3 


Measurements  are  made  and  used  to  quantitatively  determine  the  quality 
of  the  resultant  products  against  established  quality  objectives. 


Verifying  implementation 


Verification  1  Quantitative  process  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  process  management  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Verification  2  Each  project  team’s  quantitative  process  management  activities  are 
reviewed  by  the  project  manager  on  both  a  periodic  and  event-driven 
basis. 


This  review  may  be  conducted  in  conjunction  with  project  management  oversight 
reviews,  such  as  those  conducted  for  the  Project  Performance  Management  and 
Contract  Performance  Management  key  process  areas. _ 
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Quantitative  Acquisition  Management 

a  key  process  area  for  Level  4:  Quantitative 


The  purpose  of  Quantitative  Acquisition  Management  is  to  manage  the  contractual  effort  through 
the  application  of  quantitative  methods. 

Quantitative  Acquisition  Management  involves  utilizing  process  and  product  measurements  as  an 
intrinsic  part  of  management  review  and  oversight  to  quantitatively  manage  the  acquisition  of 
products. 

As  the  acquisition  organization  continues  to  attain  higher  levels  of  maturity  there  is  a  transition 
to  quantitative  methods.  This  transition  is  marked  by  the  involvement  of  all  levels  of  acquisition 
management.  The  result  represents  an  advance  from  contract  performance  management  to 
acquisition  management  using  quantitative  methods.  Another  result  of  this  transition  is  an 
expected  increase  in  the  quality  of  acquired  products. 

The  quantitative  acquisition  management  process  is  integrated  with  quantitative  process 
management.  The  actions  of  quantitative  process  management  at  the  project  level  and  across  the 
acquisition  organization  are  integral  to  acquisition  management. 

Goals 


Goal  1  Quantitative  objectives  for  the  acquired  products  are  defined. 

Goal  2  The  contracted  effort  is  managed  quantitatively. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  quantitatively 
managing  the  acquisition  of  products. 

The  term  “quantitative  management”  implies  using  quantitative  or  statistically  based 
techniques  for  analyzing  the  acquired  products,  identifying  causes  of  performance 
variations,  and  making  adjustments  to  bring  the  products  within  prescribed  limits. 


This  policy  typically  specifies  that: 

1.  Each  project’s  defined  acquisition  process  calls  for  planning  and  implementing 
quantitative  control  of  its  acquisition. 
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2.  Each  project  defines  quantitative  objectives  for  the  acquisition  of  products  and  collects 
measurements  based  on  the  project's  defined  acquisition  process. 

Commitment  2  The  acquisition  organization  has  a  written  policy  that  incorporates 

quantitative  methods  into  management  review  and  oversight  activities. 

Ability  to  perform 


Ability  1  Project  team  personnel  have  experience  and  are  trained  in  quantitative 

methods. 

Experience  means,  for  example,  having  participated  in  an  acquisition  where 
quantitative  methods  have  been  applied  to  the  process  and  products  of  the 
acquisition. _ 

Ability  2  The  members  of  the  project  team  and  groups  supporting  the  acquisition 

project  receive  orientation  on  the  goals  and  values  of  quantitative 
methods. 

Activities  performed 

Activity  1  Each  project  team  performs  its  activities  in  accordance  with  its 

documented  quantitative  acquisition  management  plans. 

These  plans  typically  cover: 

1 .  Quantitative  objectives  for  acquired  products. 

2.  Quantitative  methods  used  to  implement  management  practices. 

3.  Methods  for  the  collection  of  data  for  the  measurement  of  acquired  products. 

4.  Analysis  of  data  to  determine  deviations  from  stated  objectives. 

5.  The  resources  required  to  perform  collection  and  analysis  of  quantitative  measures. 

6.  The  quality  attributes  expected  in  acquired  products. 
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Some  examples  of  quality  attributes  are: 

functionality, 

reliability, 

reusability, 

I  maintainability,  and 
I  usability. _ 


Activity  2 


Activity  3 


Activity  4 


Activity  5 


The  quantitative  objectives  for  each  project’s  products  are  defined. 

1.  Attributes  are  identified  that  indicate  how  well  the  products  will  perform  or  how  well  they 
will  be  engineered  and  maintained. 

2.  Measurable  values  (required  and  desired)  are  defined  for  each  attribute. 

3.  The  methods  to  measure  the  attributes  are  identified. 

The  quantitative  objectives  for  each  project’s  products  are  incorporated 
into  the  solicitation  package  and  resulting  contract  according  to  the 
project’s  defined  acquisition  process. 

The  process  typically  includes  contract  mechanisms  that  provide  the  project  team 
sufficient  data  to  allow  measurement  and  analysis  of  products. _ ^ _ 


Each  project’s  evolving  products  are  measured,  analyzed,  and  compared 
to  the  project’s  established  quantitative  objectives. 

Acquisition  management  uses  the  results  of  these  actions  to  take  corrective  actions  to 
the  project’s  defined  acquisition  process  in  order  to  ensure  that  the  project’s  products 
are  acquired  in  accordance  with  established  objectives. _ 


Refer  to  Activities  2,  3,  and  4  of  the  Quantitative  Process  Management  key  process  area. 

The  project  team  utilizes  quantitative  measurements  as  a  normal  part  of 
management  review  and  oversight  of  acquired  products. 

Some  of  the  project  management  areas  that  are  tracked  using  quantitative  process  and  product 
measures  are: 

1 .  Risk  management. 

2.  Solicitation. 

3.  Evaluation. 

4.  Requirements  development  and  management. 
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Activity  6  Causal  analysis  is  conducted  on  an  event  driven  and  periodic  basis  to 

determine  special  causes  of  variances  from  the  projects’  quantitative 
objectives. 

An  example  of  a  method  to  determine  special  causes  is  cause/effect 
analysis. _ 

Activity  7  Changes  are  implemented  to  eliminate  special  causes  of  variance. 

Changes  are  typically  made  to  the  contract  requirements  and  the  project’s  defined  acquisition 
process. 

Refer  to  Activity  5  of  the  Contract  Peifonnance  Management  and  Activities  7and  8  of  the 
Quantitative  Process  Management  key  process  areas. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

quantitative  acquisition  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 

understand  the  quantitative  acquisition  management  process  capability. 


Measurement  3  Measurements  are  made  and  used  to  quantitatively  determine  the  quality 
of  the  resultant  products  against  established  quality  objectives. 


Verifying  implementation 


Verification  1  Quantitative  acquisition  management  activities  are  reviewed  by 
acquisition  organization  management  on  a  periodic  basis. 
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The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  acquisition  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Verification  2  Quantitative  acquisition  management  activities  are  reviewed  by  the 
project  manager  on  both  a  periodic  and  event-driven  basis. 
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Level  5  -  The  Optimizing  Level 


At  the  Optimizing  Level,  the  acquisition  organization  is  focused  on  continuous  process 
improvement.  An  acquisition  organization  has  the  means  to  identify  processes  that  are 
candidates  for  optimization.  Statistical  evidence  is  available  to  analyze  process  effectiveness  and 
is  used  to  refine  policies.  Technological  innovations  that  exploit  the  best  acquisition 
management  and  engineering  practices  are  identified,  appraised,  and  institutionalized. 

Level  5  acquisition  organizations  are  continuously  striving  to  reduce  variation  in  performance 
while  increasing  their  level  of  performance.  Improvement  occurs  both  by  incremental 
advancements  in  the  existing  mechanisms  and  by  innovations  using  new  technologies  and 
techniques. 

Level  5  key  process  areas  are: 

Continuous  Process  Improvement 
Acquisition  Innovation  Management 
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Continuous  Process  Improvement 

a  key  process  area  for  Level  5:  Optimizing 


The  purpose  of  Continuous  Process  Improvement  is  to  evolve  the  acquisition  processes  used  in 
the  acquisition  organization  through  managed  continuous  process  improvement.  Quantitative 
objectives  for  the  acquisition  organization’s  standard  acquisition  process  and  the  projects’ 
defined  acquisition  processes  are  the  targets  of  the  improvement  activity. 

Continuous  Process  Improvement  involves  defining  quantitative  process  improvement  objectives 
with  the  involvement  and  sponsorship  of  acquisition  organization  management.  It  is  a 
continuous  effort  to  proactively  and  systematically  identify,  appraise,  and  implement 
improvements  to  the  acquisition  organization’s  standard  acquisition  process  and  the  projects’ 
defined  acquisition  processes. 

The  commitment  to  continuous  process  improvement  is  acquisition  organization  wide.  Training 
and  incentive  programs  are  established  to  encourage  and  enable  all  acquisition  organization 
personnel  to  participate  in  the  acquisition  continuous  process  improvement  activities. 
Improvement  opportunities  are  identified  and  appraised  in  terms  of  how  well  they  move  the 
acquisition  organization  and  its  projects  toward  acquisition  continuous  process  improvement 
objectives. 

When  acquisition  process  improvements  are  approved  for  normal  practice,  the  acquisition 
organization’s  standard  acquisition  process  and  the  projects’  defined  acquisition  processes  are 
revised.  The  Process  Definition  and  Maintenance  key  process  area  defines  the  actions  for 
changing  the  acquisition  organization’s  standard  acquisition  process.  The  Project  Performance 
Management  key  process  area  defines  the  actions  for  changing  the  projects’  defined  acquisition 
processes. 

The  Acquisition  Innovation  Management  key  process  area  defines  the  actions  for  adopting  and 
transforming  new  techniques  and  technologies  into  the  acquisition  organization. 

Goals 


Goal  1  Participation  in  continuous  process  improvement  activities  is  acquisition 

organization  wide. 

Goal  2  The  acquisition  organization’s  standard  acquisition  process  and 

the  projects’  defined  acquisition  processes  are  improved  continuously. 
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Commitment  1 


Commitment  2 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  the  implementation 
of  acquisition  process  improvements. 

This  policy  typically  specifies  that: 

1.  The  acquisition  organization  has  quantitative  objectives  for  improving  the  process 
effectiveness  of  its  standard  acquisition  process. 

2.  The  acquisition  organization’s  acquisition  process  improvement  activities  are  directed 
toward  improving  the  quality  of  project  team  products  and  increasing  project  team 
productivity. 

3.  All  of  the  acquisition  organization’s  personnel  are  expected  to  participate  in  improving 
the  acquisition  processes. 

Acquisition  organization  management  actively  sponsors  process 
improvement  activities. 

Acquisition  organization  management: 

1.  Establishes  the  organization’s  strategic  objectives  and  plans  for  process  improvement. 

2.  Allocates  resources  for  process  improvement  activities. 

3.  Reviews  and  approves  the  process  improvement  plans  and  objectives. 

4.  Tracks  performance  of  the  continuous  process  improvement  activities  against  their 
defined  objectives. 

5.  Maintains  a  consistent  priority  focus  on  process  improvement  in  the  face  of  project  crises. 

6.  Ensures  that  process  improvement  issues  are  resolved  promptly. 

7.  Rewards  participation  in  the  process  improvement  activities. 


CMU/SEI-2002-TR-010 


L5-3 


Continuous  Process  Improvement 


Level  5:  The  Optimizing  Level 


Ability  1 


Ability  2 


Activity  1 


Ability  to  perform 


Adequate  resources  are  provided  for  continuous  process  improvement 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Experienced  individuals  who  have  expertise  in  defining  and  analyzing  acquisition  processes  are  made 
available  to  help  the  acquisition  organization  in  its  process  improvement  activities. _ 


Acquisition  organization  personnel  receive  required  training  in 
continuous  process  improvement. 


Some  examples  of  training  for  acquisition  management  personnel  include: 

the  principles  of  process  improvement, 

setting  and  tracking  objectives  for  process  improvement, 

motivation  and  team  building  in  a  continuous  process  improvement  environment, 
managing  technological  and  organizational  change, 
team  building,  and 

teamwork  skills  as  applied  to  continuous  process  improvement. _ 


Some  examples  of  training  for  project  personnel  include: 

the  principles  of  quality  and  process  improvement  and  the  procedures  for 
proposing  process  improvement. _ 


Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  continuous  process  improvement  plans. 

The  plans  typically: 

1 .  Identify  the  resources  required. 

2.  Present  the  quantitative  short-term  and  long-term  objectives  for  acquisition  process 
performance  and  improvement. 

3.  Specify  the  procedures  for: 

►  The  acquisition  organization  managers  overseeing  the  process  improvement 
activities. 

►  The  acquisition  managers  planning  and  coordinating  process  improvement  activities. 


L5-4 


CMU/SEI-2002-TR-010 


Level  5:  The  Optimizing  Level 


Continuous  Process  Improvement 


►  Individuals  and  project  teams  identifying,  appraising,  implementing,  and  evaluating 
acquisition  process  improvements. 

►  The  teams  developing  process  improvements  for  assigned  acquisition  process  areas. 

4.  Specify  the  administrative  and  support  procedures  required  to  maintain  process 
improvement. 

►  Administrative  procedures  to  encourage  participation  in  and  facilitate  the  process 
improvement  activities  are  included. 

►  Procedures  for  the  oversight  and  review  of  the  process  improvement  activities  by 
administrative  personnel  are  included. 

►  Procedures  for  the  recognition  of  the  roles  and  contribution  of  personnel  to  process 
improvement  are  included. 

5.  Are  reviewed  and  approved  by  acquisition  organization  management. 

6.  Are  managed  and  controlled. 

Activity  2  The  process  improvement  group  coordinates  process  improvement 

activities  throughout  the  acquisition  organization  to  facilitate 
organization-wide  participation. 

The  process  improvement  group: 

1.  Coordinates  the  definition  of  quantitative  objectives  for  acquisition  process  performance 
and  improvement  and  reviews  the  objectives  with  acquisition  organization  management 
for  its  endorsement. 

2.  Defines  the  measurement  plans  for  acquisition  process  performance. 

3.  Participates  in  the  effort  to  define  the  acquisition  organization’s  training  needs  for  process 
improvement  and  supports  the  development  and  presentation  of  training  course  materials. 

4.  Defines  and  maintains  the  procedures  for  handling  process  improvement  proposals. 

5.  Reviews  process  improvement  proposals  and  coordinates  actions  for  these  proposals. 

6.  Tracks  status,  accomplishments,  and  participation  in  the  process  improvement  activities 
and  periodically  reports  the  results  to  acquisition  organization  management. 

7.  Reviews,  approves,  manages,  and  controls  any  changes  to  the  acquisition  organization’s 
standard  acquisition  process. 

8.  Defines,  establishes,  and  maintains  the  process  improvement  records. 


CMU/SEL2002-TR-010 


L5-5 


Continuous  Process  Improvement 


Level  5;  The  Optimizing  Level 


Activity  3 


Activity  4 


Activity  5 


Activity  6 


Refer  to  the  Process  Definition  and  Maintenance  key  process  area  for  an  introduction  to  the 
acquisition  process  improvement  group  and  the  acquisition  organization 's  standard 
acquisition  process. 

Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  common 
causes  of  variances  from  acquisition  organization’s  standard  acquisition 
process. 

Changes  in  the  acquisition  organization’s  standard  acquisition  process 
are  implemented  to  correct  common  causes  of  variance. 

Appropriate  process  improvements  are  continuously  transferred  into 
practice  according  to  a  written  procedure. 

This  procedure  typically  specifies  that: 

1 .  Process  improvement  proposals  are  submitted. 

The  process  improvement  proposals  may  be  submitted  at  any  time,  by  any  member  of  the  organization, 
and  may  address  any  of  the  acquisition  processes  or  the  area  of  process  improvement. _ 

2.  Each  process  improvement  proposal  is  evaluated,  the  expected  benefits  are  determined,  a 
decision  is  made  whether  to  implement  the  proposal,  and  the  decision  rationale  is 
documented. 

3.  Implementation  of  the  approved  process  improvement  actions  is  assigned  and  planned. 

4.  The  status  of  each  process  improvement  proposal  is  tracked. 

5.  Completed  process  improvement  actions  are  reviewed,  verified,  and  approved  before 
closure. 

6.  Submitters  of  process  improvement  proposals  receive: 

►  Prompt  acknowledgment  of  their  proposals. 

►  Notification  of  the  disposition  of  their  proposals. 

7.  Appropriate  process  changes  are  incorporated  into  the  acquisition  organization’s  standard 
acquisition  process. 

Refer  to  Activities  2,  3,  and  4  of  the  Process  Definition  and  Maintenance  key  process 
area. 

8.  Appropriate  changes  are  incorporated  into  the  projects’  defined  acquisition  processes. 
Refer  to  Activity  4  of  the  Project  Performance  Management  key  process  area. 

Records  of  process  improvement  activities  are  maintained  in  the 
acquisition  organization’s  repository  for  acquisition  process  information. 
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1.  Information  about  the  initiation,  status,  and  implementation  of  the  process  improvement 
proposals  is  maintained. 

2.  Historical  data  are  maintained  and  reports  produced  on  process  improvement  activities 
and  results. 


Some  examples  of  records  and  reports  include  the: 

projects’  productivity,  quality,  and  schedule  performances; 

projects’  deficiency  histories; 

organizational  quality  and  productivity  trends;  and 

cost,  schedule,  and  productivity  of  acquisition  process  definition  and  maintenance. 


Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

continuous  process  improvement  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 

completion  of  milestones. _ _ 

Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 
understand  the  continuous  process  improvement  process  capability  . 

Some  examples  of  measurements  include: 

effort  expended, 
time  expended,  and 

funds  expended. _ 

Measurement  3  Measurements  are  made  and  used  to  quantitatively  determine  the  quality 
of  the  resultant  products  against  established  quality  objectives. 


Verifying  implementation 


Verification  1 


Continuous  process  improvement  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 
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The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  continuous  process  improvement  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Some  examples  of  review  subjects  include: 

participation  in  the  continuous  process  improvement  activities, 
process  performance, 
needed  changes  in  objectives, 
issues,  and 

revisions  to  the  continuous  process  improvement  plans  as  appropriate. 


Verification  2  Acquisition  organization  managers  and  project  managers  receive 

feedback  on  the  status  and  results  of  continuous  process  improvement 
activities. 

Feedback  is  provided  on  a  periodic  or  event-driven  basis  and  includes: 

1.  A  summary  of  the  major  continuous  process  improvement  activities. 

2.  Significant  innovations  and  actions  taken  to  address  continuous  process  improvement. 

3.  A  summary  status  of  process  improvement  proposals  that  are  submitted,  opened,  and 
completed  or  closed. 

4.  Reports  on  the  effectiveness  of  implemented  process  improvements. 
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Acquisition  Innovation  Management 

a  key  process  area  for  Level  5:  Optimizing 


The  purpose  of  Acquisition  Innovation  Management  is  to  continually  improve  the  acquisition 
process  through  the  adoption  and  transfer  of  new  techniques  and  technologies.  Acquisition 
innovation  management  is  a  primary  responsibility  of  the  acquisition  organization;  however,  the 
adoption  activity  may  be  carried  out  through  individual  acquisition  projects.  While  a  project  can 
act  by  itself,  the  environment  for  adoption  should  be  fostered  and  led  by  the  acquisition 
organization. 

Acquisition  Innovation  Management  involves  the  identification,  appraisal,  implementation, 
adoption,  and  transfer  of  new  techniques  and  technologies  that  support  the  acquisition  process. 

The  focus  is  on  improving  the  acquisition  process  through  the  adoption  and  implementation  of 
new  techniques  and  technologies.  Adoption  of  new  techniques  and  technologies  is  accomplished 
in  concert  with  continuous  process  improvement  (refer  to  the  Continuous  Process  Improvement 
key  process  area). 

Acquisition  innovation  management  of  new  techniques  and  technologies  encompasses  a  range  of 
possibilities.  These  techniques  and  technologies  are  those  that  are  new  on  the  horizon  or  are  new 
to  the  acquisition.  They  may  range  from  introduction  of  a  new  technique  to  the  project  (such  as 
automated  documentation)  to  adoption  of  a  new  management  strategy  (e.g.,  product  line)  at  the 
acquisition  organization  level.  The  acquisition  organization  and  the  project  act  in  cooperation  to 
implement  new  techniques  and  technologies  that  may  provide  a  specific  benefit  to  the  project,  as 
well  as  an  overall  benefit  to  the  organization. 

Goals 


Goal  1  The  acquisition  organization  proactively  adopts  and  implements  new 

techniques  and  technologies  to  improve  the  standard  acquisition  process 
and  acquisition  management. 

Goal  2  Participation  in  the  acquisition  innovation  management  process  is 

organization  wide. 
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Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  acquisition 
innovation  management  activities. 

This  policy  typically  specifies  that: 

1.  New  techniques  and  technologies  for  possible  implementation  in  the  acquisition 
organization’s  standard  acquisition  process  are  continually  appraised. 

2.  New  techniques  and  technologies  to  determine  their  value,  cost,  risk,  and  benefit  to  the 
acquisition  process  are  appraised. 

3.  Implementation  of  new  techniques  and  technologies  is  managed  and  controlled. 

Commitment  2  Acquisition  organization  management  sponsors,  actively  supports,  and 
provides  leadership  for  acquisition  innovation  management. 

Commitment  3  Responsibility  for  acquisition  innovation  management  activities  is 
designated. 

Ability  to  perform 


Ability  1 


Ability  2 


Ability  3 


A  group  that  performs  and  coordinates  the  acquisition  innovation 
management  activities  for  the  acquisition  organization  exists. 

Adequate  resources  are  provided  for  acquisition  innovation  management 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  acquisition  innovation  management  activities 
have  experience. 


Experience  means,  for  example,  having  had  multiple  acquisition  management  roles 
on  several  projects,  understanding  the  application  of  techniques  and  technologies  in 
the  acquisition  process,  and  understanding  the  objectives  of  the  acquisition 
organization. _ 
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Activities  performed 


Activity  1  The  acquisition  organization  and  each  project  perform  their  activities 

according  to  their  respective  documented  acquisition  innovation 
management  plans. 

The  plans  typically  cover; 

1.  The  appraisal  of  new  techniques  and  technologies  to  determine  their  applicability  and 
appropriateness  for  the  acquisition  organization. 

Some  examples  of  new  techniques  and  technologies  include: 

the  use  of  a  new  documentation  scheme, 

the  employment  of  new  evaluation  methods, 

the  employment  of  new  acquisition  paradigms, 

the  employment  of  asset  management  (reusable  components), 

the  implementation  of  software  architecture  managed  development,  and 

the  use  of  product  line  implementation  and  management. _ 

2.  The  resources  required. 

3.  Assignment  of  responsibilities. 

4.  Review  and  appraisal  of  the  acquisition  innovation  management  activities. 

5.  The  detailing  of  specific  implementation  and  evaluation  practices  and  procedures. 

6.  Preparation  of  process  improvement  proposals. 

Refer  to  Activities  1  and  5  of  the  Continuous  Process  Improvement  key  process  area. 

Activity  2  The  group  responsible  for  conducting  acquisition  innovation 

management  activities  conducts  routine  and  periodic  appraisals  of  new 
techniques  and  technologies  as  candidates  for  inclusion  in  the  acquisition 
organization’s  standard  acquisition  process. 

New  approaches  and  technologies  are  appraised  to  determine  their  effect  on  quality 
and  productivity  and  results  are  reported  to  acquisition  organization  management. 


Refer  to  Activities  2  and  5  of  the  Continuous  Process  Improvement  key  process  area. 

Activity  3  The  group  responsible  for  conducting  acquisition  innovation 

management  adapts,  pilots,  and  includes  new  techniques  and  technologies 
beneficial  to  the  acquisition  organization  into  the  standard  acquisition 
process. 
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Activity  4  Piloted  efforts  assigned  to  project  teams  are  performed  in  accordance 

with  its  documented  acquisition  innovation  management  plans. 

The  plans  typically  cover: 

1.  Management  of  the  implementation  process  for  the  inclusion  of  the  new  technique  or 
technology. 

2.  Implementation  process  of  the  adopted  technique  or  technology. 

3.  Evaluation  of  the  effect  of  the  implemented  technique  or  technology. 

4.  Resources  needed  to  manage  the  implementation  of  the  activity. 

Activity  5  The  acquisition  organization,  working  with  the  projects,  implements 

activities  to  foster  an  organization-wide  environment  that  facilitates 
adoption  of  initiatives  beneHcial  to  the  acquisition  organization. 

Activity  6  Acquisition  management  personnel  are  kept  informed  of  new 

technologies. 

1.  Information  on  new  techniques  and  technologies  is  made  available. 

2.  Information  on  techniques  and  technologies  already  in  use  within  the  acquisition 
organization  is  disseminated. 

3.  Information  on  the  status  of  new  techniques  and  technologies  being  implemented  within 
the  acquisition  organization  is  disseminated. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

acquisition  innovation  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

compliance  with  established  processes, 
progress  toward  completion,  and 
completion  of  milestones. _ 


Measurement  2  Performance  measurements  are  made  and  used  to  characterize  and 

understand  the  acquisition  innovation  management  process  capability. 
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Some  examples  of  measurements  include: 

effort  expended, 
time  expended,  and 

funds  expended. _ 


Measurement  3  Measurements  are  made  and  used  to  quantitatively  determine  the  quality 
of  the  resultant  products  against  established  quality  objectives. 

Verifying  implementation 


Verification  1  Acquisition  innovation  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  innovation  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 

Verification  2  Acquisition  innovation  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Appendix  A;  Glossary  of  Terms _ 

acceptance  criteria  -  The  criteria  that  a  product  entity  or  component  must  satisfy  in  order 
to  be  accepted  by  the  buyer,  or  other  authorized  representative. 

acceptance  testing  -  Formal  testing  conducted  to  determine  whether  or  not  a  product 
satisfies  its  acceptance  criteria  and  to  enable  the  customer  to  determine  whether  or  not  to 
accept  the  product  [IEEE-STD-6 10]. 

acquisition  -  The  process  of  obtaining  through  contract. 

acquisition  management  personnel  -  Those  individuals  who  are  trained,  educated,  or 
experienced  in  acquisition  management  and  who  are  either  assigned  to  or  support  the  project 
team  in  the  performance  of  acquisition  activities. 

acquisition  organization  -  That  entity  which  has  the  oversight  responsibility  for  the 
acquisition  project  and  which  may  have  purview  over  the  acquisition  activities  of  a 
number  of  projects  or  contract  actions. 

acquisition  plans  -  The  collection  of  plans,  both  formal  and  informal,  used  to  express  how 
acquisition  activities  will  be  performed;  for  example,  the  Software  Acquisition  Risk 
Management  Plan  or  Project  Management  Plan. 

acquisition  process  -  A  set  of  activities  that  are  used  to  acquire  products. 

►  acquisition  organization’s  standard  acquisition  process  -  The  acquisition 
organization’s  fundamental  acquisition  process  which  guides  the  establishment  of 
each  project’s  defined  acquisition  process. 

►  project’s  defined  acquisition  process  -  The  project’s  tailored  version  of  the 
acquisition  organization’s  standard  acquisition  process. 

acquisition  process  assets  -  A  collection  of  entities,  maintained  by  an  organization,  for  use  by 
projects  in  developing,  tailoring,  maintaining,  and  implementing  their  acquisition  processes. 


Some  examples  of  these  acquisition  process  assets  include: 
the  effort  expended, 

organization’s  standard  acquisition  process, 
descriptions  of  the  life  cycles  approved  for  use, 

the  guidelines  and  criteria  for  tailoring  the  acquisition  organization’s  standard 
acquisition  process, 

the  organization’s  acquisition  process  database,  and 
a  library  of  acquisition  process-related  documentation. _ _ 
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Any  entity  that  the  organization  considers  useful  in  performing  the  activities  of 
process  definition  and  maintenance  could  be  included  as  a  process  asset. 

acquisition  process  improvement  group  -  This  group  is  responsible  for  the  definition, 
improvement,  and  maintenance  of  the  acquisition  organization’s  standard  acquisition  process 
and  related  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with  the 
projects  and  related  elements  of  the  organization. 

acquisition  process-related  documentation  -  Documents  and  document  fragments  that  may  be 
of  use  to  future  project  teams  when  tailoring  the  acquisition  organization’s  standard 
acquisition  process.  The  examples  may  cover  subjects  such  as  a  project’s  defined  acquisition 
process,  standards,  procedures,  acquisition  risk  management  plans,  and  training  materials. 

acquisition  process  repository  -  A  collection  of  acquisition  process  information  (e.g., 
estimated  and  actual  data  on  software  project  size,  effort,  and  cost;  and  project  team 
productivity  and  quality  data)  gathered  from  the  acquisition  projects  that  is  maintained  by  the 
acquisition  organization  to  support  its  acquisition  definition,  maintenance,  and  improvement 
activities. 

acquisition  project  -  An  undertaking  that  is  focused  on  acquiring  products 

activity  -  A,ny  step  taken  or  function  performed,  either  mental  or  physical,  toward 
achieving  some  objective.  Activities  include  all  the  work  the  managers  and  technical 
staff  do  to  perform  the  tasks  of  the  project  and  organization. 

adapt  -  To  modify  a  process,  standard,  or  procedure  to  better  match  process  or  product 
requirements. 

application  domain  -  A  bounded  set  of  related  products  (i.e.,  products  that  address  a 
particular  type  of  problem).  Development  and  maintenance  in  an  application  domain 
usually  require  special  skills  and/or  resources.  Examples  include  payroll  and  personnel 
systems,  avionics,  command  and  control  systems,  compilers,  and  expert  systems. 

appraise  -  To  evaluate  the  worth,  significance,  or  status  of. 

attributes  -  Characteristics  of  a  product  such  as  reliability,  maintainability,  portability, 
and  complexity.  These  characteristics  are  sometimes  referred  to  as  quality  attributes. 

baseline  -  A  specification  or  product  that  has  been  formally  reviewed  and  agreed  upon, 
that  thereafter  serves  as  the  basis  for  further  development,  and  that  can  be  changed  only 
through  formal  change  control  procedures  [IEEE-STD-610]. 

capability  -  Having  the  needed  attributes  to  perform  or  accomplish. 
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capability  maturity  model  (staged)  -  A  description  of  the  stages  through  which 
organizations  evolve  as  they  define,  implement,  measure,  control,  and  improve  their 
processes.  The  model  provides  a  guide  for  selecting  process  improvement  strategies  by 
facilitating  the  determination  of  current  process  capabilities  and  the  identification  of  the 
issues  most  critical  to  quality  and  process  improvement. 

causal  analysis  -  The  analysis  of  defects  to  determine  their  cause. 

change  control  -  The  review,  approval/disapproval,  implementation,  tracking,  closure, 
and  status  reporting  of  proposed  changes  to  an  item  (change  management). 

commitment  -  A  pact  that  is  freely  assumed,  visible,  and  expected  to  be  kept  by  all  parties. 

configuration  -  In  configuration  management,  the  functional  and  physical  characteristics 
of  hardware  or  software  as  set  forth  in  technical  documentation  or  achieved  in  a  product 
[IEEE-STD-610]. 

configuration  management  -  A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  identify  and  document  the  functional  and  physical  characteristics  of  a 
configuration  item,  control  changes  to  those  characteristics,  record  and  report  change 
processing  and  implementation  status,  and  verify  compliance  with  specified  requirements 
[IEEE-STD-610]. 

consistency  -  The  degree  of  uniformity,  standardization,  and  freedom  from  contradiction 
among  the  documents  or  parts  of  a  product  or  component  [IEEE-STD-610]. 

contract  -  A  binding  agreement  between  two  or  more  parties  that  establishes  the 
requirements  for  the  products  and  services  to  be  acquired. 

contract  integrity  -  The  adherence  and  compliance  to  contractual  and  legal  policies, 
regulations,  and  other  guidance. 

contract  terms  and  conditions  -  The  stated  legal,  financial,  and  administrative  aspects  of  a 
contract. 

contractor  -  (See  supplier.) 

critical  path  -  A  series  of  dependent  tasks  for  a  project  that  must  be  completed  as  planned 
to  keep  the  entire  project  on  schedule. 

deficiency  -  An  inadequacy  in  the  quality  of  a  process,  product,  or  service. 
defined  level  -  (See  maturity  level.) 
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deliverable  -  A  product  that  is  required  by  the  contract  to  be  delivered  to  the  acquirer  or  other 
designated  recipient. 

deviation  -  A  noticeable  or  marked  departure  from  the  appropriate  norm,  plan,  standard, 
procedure,  or  variable  being  reviewed. 

effective  -  Adequate  to  accomplish  the  intended  purpose. 

efficient  -  Productive,  without  waste. 

end  user  -  The  individual  or  group  who  will  use  the  product  for  its  intended  operational  use 
when  it  is  deployed  in  its  environment. 

end  user  representatives  -  A  selected  sample  of  end  users  who  represent  the  total  population 
of  end  users. 

evaluation  -  The  process  of  determining  satisfaction  of  requirements.  Evaluations  may 
include  methods  such  as  analyses,  inspections,  reviews,  and  tests.  For  acquisition, 
evaluations  are  conducted  throughout  the  contract  period  of  performance. 

event-driven  review  -  A  review  that  is  performed  based  on  the  occurrence  of  an  event  within 
the  project  (e.g.,  a  formal  review  or  the  completion  of  a  life  cycle  stage).  (See  periodic 
review  for  contrast.) 

findings  -  The  conclusions  of  an  assessment,  evaluation,  audit,  or  review  that  identify  the 
most  important  issues,  problems,  or  opportunities  within  the  area  of  investigation. 

function  -  A  set  of  related  actions,  undertaken  by  individuals  or  tools  to  accomplish  a  set 
purpose  or  end. 

goals  -  The  aggregate  result  achieved  by  the  effective  implementation  of  the  common 
features  of  a  key  process  area.  The  goals  signify  the  scope  and  intent  of  each  key  process 
area. 

group  -  An  assemblage  of  personnel  organized  to  serve  a  specific  purpose  or  accomplish  a 
task.  A  group  may  vary  from  a  single  individual  assigned  part  time,  to  several  part-time 
individuals  assigned  from  other  organizations,  to  several  individuals  dedicated  full-time. 

initial  level  -  (See  maturity  level.) 

institutionalization  -  The  building  of  infrastructure  and  corporate  culture  that  supports 
methods,  practices,  and  procedures  so  that  they  are  the  ongoing  way  of  doing  business,  even 
after  those  who  originally  defined  them  are  gone. 
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instrumentation  -  The  application  of  instruments  (or  metrics)  for  observation,  measurement, 
or  control. 

integrate  -  To  make  into  a  whole  by  bringing  all  parts  together. 

key  process  area  -  A  principle  component  of  a  capability  maturity  model’s  organizational 
structure  that  clusters  related  goals  and  common  features  which  model  a  specific  portion  of 
the  process. 

life  cycle  -  (See  product  life  cycle.) 

managed  and  controlled  -  Implies  that  the  version  of  the  work  product  in  use  at  a  given  time 
(past  or  present)  is  known  (i.e.,  version  control),  and  changes  are  incorporated  in  a  controlled 
manner  (i.e.,  change  control). 

manager  -  A  role  that  encompasses  providing  technical  and  administrative  direction  and 
control  to  individuals  performing  tasks  or  activities  within  the  manager’s  area  of 
responsibility.  The  traditional  functions  of  a  manager  include  planning,  resourcing, 
organizing,  directing,  and  controlling  work  within  an  area  of  responsibility. 

maturity  level  -  A  well-defined  evolutionary  plateau  toward  achieving  a  mature  acquisition 
process.  The  five  maturity  levels  in  the  SA-CMM  are  Initial,  Repeatable,  Defined, 
Quantitative,  and  Optimizing. 

measure  -  To  ascertain  the  characteristics  or  features  (extent,  dimension,  quantity,  capacity, 
and  capability)  of  something,  especially  by  comparing  with  a  standard. 

measurement  -  The  dimension,  capacity,  quantity,  or  amount  of  something  (e.g.,  300  source 
lines  of  code  or  seven  document  pages  of  design). 

method  -  A  reasonably  complete  set  of  rules  and  criteria  that  establishes  a  precise  and 
repeatable  way  of  performing  a  task  and  arriving  at  a  desired  result. 

methodology  -  A  collection  of  methods,  procedures,  and  standards  that  defines  an  integrated 
synthesis  of  approaches. 

milestone  -  A  scheduled  event  for  which  some  individual  is  accountable  and  that  is  used  to 
measure  progress. 

non-developmental  item  (NDI)  -  An  item  that  is  available  for  delivery  prior  to  award  of  the 
contract.  NDI  may  be  referred  to  as  a  reusable  item,  government  furnished  item,  or 
commercially  available  item,  depending  on  its  source. 
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ojferor  -  A  supplier  who  submits  a  proposal  in  response  to  a  solicitation  package. 
optimizing  level  -  (See  maturity  level.) 

organization  -  The  parent  organization  of  the  acquisition  organization. 

organization’s  measurement  program  -  The  set  of  related  elements  for  addressing  an 
organization’s  measurement  needs.  It  includes  the  definition  of  organization-wide 
measurements,  methods  and  practices  for  collecting  organizational  measurements  and 
analyzing  data,  and  measurement  goals  for  the  organization. 

orientation  -  An  overview  or  introduction  to  a  topic. 

peer  review  -  A  review  of  products  or  services,  following  defined  procedures,  by  peers  for  the 
purpose  of  identifying  deficiencies  and  improvements. 

periodic  review  -  A  review  that  occurs  at  specified  regular  time  intervals.  (See  event-driven 
review  for  contrast.) 

policy  -  A  guiding  principle,  typically  established  by  senior  management,  that  is  adopted  by 
an  organization  or  project  to  influence  decisions. 

prime  contractor  -  An  individual,  partnership,  corporation,  or  association  that  administers  a 
subcontract  to  design,  develop,  and/or  manufacture  one  or  more  products. 

procedure  -  A  written  description  of  a  course  of  action  to  be  taken  to  perform  a  given  task 
[IEEE-STD-610]. 

process  -  A  set  of  activities  performed  for  a  given  purpose  (e.g.,  a  software  acquisition 
process). 

process  capability  -  The  range  of  expected  results  that  can  be  achieved  by  following  a 
process.  (See  process  performance  for  contrast.) 

process  capability  baseline  -  A  documented  characterization  of  the  range  of  expected  results 
that  would  normally  be  achieved  by  following  a  specific  process  under  typical  circumstances. 
A  process  capability  baseline  is  typically  established  at  an  organizational  level.  (See  process 
performance  baseline  for  contrast.) 

process  measurement  -  The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for  the  purpose  of  characterizing  and 
understanding  the  process. 
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process  performance  -  Measurements  of  the  actual  results  achieved  by  following  a  process. 
(See  process  capability  for  contrast.) 

product  -  something  created  or  produced  by  human  or  mechanical  effort  or  by  a  natural 
process.  For  acquisition  the  product  may  include  hardware  and  software  or  a  combination. 

product  life  cycle  -  The  period  of  time  that  begins  when  a  product  is  conceived  and  ends 
when  the  product  is  no  longer  available  for  use.  The  life  cycle  typically  includes  a  concept 
phase,  requirements  phase,  design  phase,  implementation  phase,  test  phase,  installation  and 
checkout  phase,  operation  and  maintenance  phase,  and,  sometimes,  retirement  phase  [lEEE- 
STD-610]. 

project  -  An  undertaking  that  is  focused  on  acquiring  or  developing  a  specific  product  or 
products.  Typically,  a  project  has  its  own  funding,  cost  accounting,  and  delivery  schedule. 

project  manager  -  The  role  with  total  business  responsibility  for  an  entire  project;  the 
individual  who  directs,  controls,  administers,  and  regulates  a  project.  The  project  manager  is 
the  individual  ultimately  responsible  to  the  customer  or  end  user. 

project  office  -  The  aggregate  of  individuals  assigned  the  primary  responsibility  for 
acquisition  in  the  contracted  effort.  A  project  office  may  vary  in  size  from  a  single  individual 
assigned  part  time  to  a  large  organization  assigned  full  time. 

project  team  -  All  individuals,  including  matrix  support  and  support  contractors,  that  have  an 
assigned  acquisition  responsibility  in  the  acquisition  effort.  A  project  team  may  vary  in  size 
from  a  single  individual  assigned  part  time  to  a  large  organization  assigned  full  time. 

quality  -  The  degree  to  which  a  process,  product,  or  service  satisfies  a  specific  set  of 
attributes  or  requirements. 

quantitative  control  -  Any  quantitative  or  statistically  based  technique  appropriate  to  analyze 
an  acquisition  process,  identify  special  causes  of  variations  in  the  performance  of  the 
acquisition  process,  and  bring  the  performance  of  the  acquisition  process  within  well-defined 
limits. 

quantitative  level  -  (See  maturity  level.) 
repeatable  level  -  (See  maturity  level.) 

required  training  -  Training  required  by  the  acquisition  organization.  (See  training  for 
contrast.) 

requirement  -  needed  property  [attribute]  of  an  entity;  a  needed  quality,  condition,  capability, 
or  performance  demanded  of  an  entity  in  accordance  with  fixed  regulations.  Fixed 
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regulations  could  be  a  contract,  standard,  specification,  or  other  documents.  The  following 
terms  are  derived  from  this  definition  for  acquisitions: 

product  requirement  -  A  condition  or  capability  that  must  be  met  or  possessed  by  a 
product  or  product  component  to  satisfy  a  condition  or  capability  needed  by  the  user 
to  solve  a  problem.  [IEEE-STD-610] 

product-related  contractual  requirements  -  All  technical  and  non-technical 
requirements  related  to  the  product  or  product  component  portion  of  an  acquisition; 
requirements  necessary  to  acquire  a  product. 

non-technical  requirements  -  Contractual  agreements,  conditions,  and  terms  that 
affect  how  products  are  to  be  acquired. 

technical  requirements  -  Properties  [attributes]  of  the  products  to  be  acquired;  e.g., 
products  being  acquired  may  include  a  business  case  or  software. 

evaluation  requirements  -  Those  requirements  that  specify  what  processes,  associated 
methods,  and  results  are  to  be  used  to  determine  satisfaction  of  agreed  upon 
requirements  for  products  being  acquired. 

contractual  requirements  -  All  technical  and  non-technical  requirements  related  to  the 
products  being  acquired.  These  also  include  requirements  to  support  the 
administration  of  the  contract.  Contractual  requirements  are  developed  and  included 
into  the  solicitation  package. 

allocated  requirements-  The  subset  of  product  requirements  that  are  to  be 
implemented  by  a  product  component  such  as  the  software. 


risk  -  The  possibility  of  suffering  loss,  injury,  disadvantage,  or  destruction. 

risk  management  -  The  process  associated  with  identifying,  evaluating,  mitigating,  and 
controlling  project  risks. 

role  -  A  unit  of  defined  responsibilities  that  may  be  assumed  by  one  or  more  individuals. 

selection  official  -  That  individual  within  the  organization  who  is  authorized  to  select  the 
offeror  (and  commit  the  organization)  for  award  of  a  contract. 

solicitation  package  -  When  seeking  suppliers  for  a  particular  acquisition,  it  is  the 
information  distributed  which  tells  the  interested  bidders  what  the  requirements  of  the 
acquisition  (contractual  requirements),  are  how  to  prepare  their  proposals  (responses),  how 
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proposals  (responses)  will  be  evaluated,  and  when  to  submit  their  proposals  (responses). 
Sometimes  called  request  for  proposals  (RFP)  or  task  order  packages. 

staff-  Those  personnel  resources  available  to  the  project  manager  to  assist  in  the  execution  of 
the  project.  Staff  personnel  can  be  persons  assigned  full-time,  from  matrixed  in-house 
support  organizations,  and/or  from  support  contractors. 

standard  -  Mandatory  requirements  employed  and  enforced  to  prescribe  a  disciplined 
uniform  approach  to  development  or  acquisition. 

statement  of  work  -  A  description  of  all  the  work  required  to  complete  a  project,  which  is 
provided  by  the  customer. 

subcontractor  -  An  individual,  partnership,  corporation,  or  association  that  contracts  with  an 
organization  (i.e.,  the  prime  contractor)  to  design,  develop,  and/or  manufacture  one  or  more 
products. 

supplier  -  The  entity  delivering  the  product  being  acquired  by  contract  even  if  that  entity 
is  part  of  the  acquiring  organization. 

support  -  The  process  of  modifying  a  product  or  component  after  delivery  to  correct  faults, 
improve  performance  or  other  attributes,  or  adapt  to  a  changed  environment  [lEEE-STD- 
610].  As  used  in  this  model,  support  is  synonymous  with  logistics. 

technology  -  The  application  of  science  and/or  engineering  in  accomplishing  a  particular 
result. 

traceability  -  The  ability  to  trace,  in  both  the  forward  and  backward  directions,  the  lineage  of 
a  requirement  from  its  first  level  inception  and  subsequent  refinement  to  its  implementation 
in  a  product  and  the  documentation  associated  with  the  product. 

training  -  Project  team  training.  (See  required  training  for  contrast.) 

training  group  -  The  collection  of  individuals  (both  managers  and  staff)  who  are  responsible 
for  coordinating  and  arranging  the  training  activities  for  an  organization.  This  group  typically 
prepares  and  conducts  most  of  the  training  courses  and  coordinates  use  of  other  training 
vehicles. 

training  program  -  The  set  of  related  elements  that  focuses  on  addressing  an  organization’s 
training  needs.  It  includes  an  organization’s  training  plan,  training  materials,  development  of 
training,  conduct  of  training,  training  facilities,  evaluation  of  training,  and  maintenance  of 
training  records. 
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transition  -  The  process  of  transferring  responsibility  for  support  of  the  acquired  products 
from  the  contractor  to  the  support  organization. 

user  -  (See  end  user.) 

verify  -  To  prove  to  be  true  by  demonstration,  evidence,  or  testimony. 

waiver  -  A  document  stating  a  cancellation  or  reduction  of  a  requirement. 

work  product  -  Any  artifact  that  is  an  output  of  defining,  maintaining,  or  using  a  process. 
They  can  include  process  descriptions,  plans,  procedures,  requirements  definition,  design, 
and  software. 
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Mapping  Features  to  Goals 


Since  satisfying  a  key  process  area  implies  addressing  each  of  the  goals  for  that  key 
process  area,  it  may  be  helpful  to  understand  the  relationships  between  the  common 
features  and  the  goals.  The  following  tables  map  each  common  feature  to  its  associated 
goal(s). 

Features,  like  key  process  areas,  are  not  independent  of  one  another.  Many  features  map 
to  more  than  one  goal.  For  example,  there  is  usually  only  one  policy  statement  per  key 
process  area,  and  it  covers  all  of  the  goals  for  that  key  process  area. 


Software  Acquisition  Planning 


Goal 

Commitment 

Ability 

Activity 

Measurement 

Verification 

1 

1,2 

1.2,3 

1,2,3,4,5,6,7 

1 

1,2 

2 

1 

1,2,3 

4.6,7 

1 

1,2 

Solicitation 


Goal 

Commitment 

Measurement 

Verification 

1 

1, 2,3,4 

1,2, 3,4 

1,2, 3,4 

1 

1,2 

2 

1.2.3, 4 

1,2, 3.4 

1,3, 4,5.7 

1 

1,2 

3 

1,2.3, 4 

1, 2,3,4 

1,3,4,5,6,7 

1 

1,2 

Requirements  Development  and  Management 


Goal 

Commitment 

fEmm 

Measurement 

Verification 

1 

1,2 

1,2,3 

1,2,3,4,5 

1 

1.2 

2 

1,2 

1.2,3 

1,2,3,4,6 

1 

1,2 

3 

1,2 

1.2,3 

1, 2,3,4, 5 

1 

1.2 

4 

1,2 

1,2,3 

1,2 

1 

1,2 

Project  Management 


Goal 

Commitment 

Ability 

Measurement 

Verification 

1,2 

1,2,3 

1,2,3,4,5,6,7 

1 

1,2 

1,2 

1,2 

1,3,4,5,7 

1 

1.2 

1,2 

1,2 

1,3,4,5,6 

1 

1.2 

Contract  Tracking  and  Oversight 


Goal 

Commitment 

Ability 

Measurement 

Verification 

1 

1,2,3 

1,2,3 

1,2,3,4,5,6,7 

1 

1,2 

2 

1,3 

1,2,3 

1, 2,3,5, 7 

1 

1,2 

3 

1,2,3 

1,2,3 

1,3,5,6,7 

1 

1,2 
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Evaluation 


Goal 

Commitment 

Ability 

Activity 

Measurement 

Verification 

1 

1,2 

1,2, 3, 4 

1,2 

1 

1,2 

2 

1,2 

1,2, 3, 4 

1,3 

1 

1,2 

3 

1,2 

1,2,3, 4 

1,4,5 

1 

1.2 

Transition  to  Support 


Goal 

Commitment 

Ability 

Activity 

Measurement 

Verification 

1,2,3 

1,2,3,4,5,6 

1,2, 3,4 

1 

1,2 

1,2,3 

1,2, 3,4, 5, 6 

1,2,3 

1 

1,2 

1,2,3 

1,2,5, 6 

1,2,4 

1 

1,2 

Process  Definition  and  Maintenance 


Goal 

Commitment 

Ability 

mmsm 

Measurement 

Verification 

1 

1,2,3 

1.2,3 

1,2, 3, 4, 5, 6.7 

1,2 

1 

2 

1,2,3 

1,2, 3, 4 

1,2, 4,6,7 

1,2 

1 

3 

1,2,3 

1,2, 3, 4 

1.2,3,4,5,6,7 

1.2 

1 

User  Requirements 


Ability 

Activity 

Measurement 

Verification 

1 

1.2,3 

1,2,3 

1.2, 3,4 

1,2 

1,2 

2 

1,2.3 

1, 2,3,4 

1.5 

1,2 

1,2 

3 

1,2,3 

1.2,3 

1,6 

1,2 

1,2 

Project  Performance  Management 


Goal 

Commitment 

Ability 

Measurement 

Verification 

1 

1 

1 

1 ,2, 3, 4, 5, 6, 7 ,8, 
9,10,11 

1,2 

1.2 

2 

1 

1 

2,5,6,7,8,9,10 

1,2 

1,2 

Contract  Performance  Management 


Goai 

Commitment 

Mmsm 

Measurement 

Verification 

1 

1 

1 

1.2, 3,4,5 

1.2 

1.2 

2 

1 

1 

1, 5,6,7 

1,2 

1.2 

Acquisition  Risk  Management 


Goai 

Commitment 

1  niiii'B 

Measurement 

Verification 

1 

1,2 

2,3 

2,4 

1,2 

1.2 

2 

1,2 

1,2,3 

1,2,3,5,6 

1,2 

1,2 

3 

1,2 

1,2,3 

1,2,3,6.7 

1,2 

1,2 
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Training  Program  Management 


Goal 

Commitment 

Abiiity 

Activity 

Measurement 

Verification 

1 

1,2 

1,2, 3, 4 

1.2, 3, 4, 5 

1,2 

1 

2 

1.2 

1,2,3 

1,3,6 

1,2 

1 

Quantitative  Process  Management 


Goal 

Commitment 

Ability 

Measurement 

Verification 

1 

1,2 

1,2,3, 4 

2,3,4, 5,6, 7,8 

1.2,3 

1,2 

2 

1.2 

1,2,3 

1,8 

1,2,3 

1 

Quantitative  Acquisition  Management 


Goal 

Commitment 

Ability 

Activity 

Measurement 

Verification 

1 

1,2 

1.2 

1,2,3 

1,2,3 

1.2 

2 

1,2 

1,2 

1,3,4,5,6,7 

1,2,3 

1,2 

Continuous  Process  Improvement 


Goal 

Commitment 

Measurement 

Verification 

1 

1,2 

1,2 

1,2,6 

1,2,3 

1,2 

2 

1.2 

1,2 

1,3,4, 5,6 

1.2,3 

1,2 
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